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ABSTRACT 

In  the  rapidly  changing  environment  of  mobile  communications,  the  importance  of  the 
mobile  satellite  (e.g.,  low  earth  orbit  satellites  (LEOsats))  networks  will  increase  due  to 
their  global  visibility  and  connection.  Multicasting  is  an  effective  communication 
method  in  terms  of  frequency  spectrum  usage  for  a  LEO  network.  It  is  devised  to 
provide  lower  network  traffic  (i.e.,  one-to-many  transmissions).  This  research  examines 
the  system  perfonnance  of  two  dissimilar  terrestrially-based  multicasting  protocols:  the 
Distance  Vector  Multicast  Routing  Protocol  (DVMRP)  and  the  On  Demand  Multicast 
Routing  Protocol  (ODMRP).  These  two  protocols  are  simulated  in  large  group 
membership  density  and  in  the  presence  of  satellite  failures.  Two  different  algorithms 
are  developed  and  used  to  select  critical  satellites  for  degrading  a  LEO  network 
constellation.  The  simulation  results  show  that  the  ODMRP  protocol  successfully 
reconfigured  routes  in  large  group  membership  density  areas  and  in  satellite  failure 
conditions.  Results  also  show  that  the  ODMRP  provided  reliable  packet  delivery. 
However,  ODMRP  showed  an  enormous  end-to-end  delay  in  severe  satellite  failure 
conditions.  This  result  is  attributable  to  the  delayed  route  refreshing  procedure  of 
ODMRP.  In  contrast,  the  DVMRP  suffered  from  broken  routes  and  complexity  in  the 
large  group  membership  density  and  in  satellite  failure  conditions.  It  had  a  smaller 
packet  delivery  ratio  than  the  ODMRP  (approximately  85.5%  versus  98.9%  for  the  80 
user  case).  The  DVMRP  showed  scalable  and  stable  end-to-end  delay  under  multiple 
failed  satellite  conditions.  The  large  group  membership  density  and  the  multiple 
satellite  failure  conditions  provide  a  more  complete  assessment  for  these  two  protocols. 
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Multicast  Routing  Algorithms  and  Failure  Analyses 
for  Low  Earth  Orbit  Satellite  Communication  Networks 


Chapter  1:  Introduction 


1.1  Background 

The  Internet  routes  datagrams  using  a  one-to-one  (unicast)  method.  Unicast  routing 
sends  individual  datagrams  to  every  recipient.  Unicast  routing  wastes  bandwidth 
because  multiple  copies  of  the  datagram  must  be  sent.  On  the  other  hand,  multicast 
routing  sends  a  single  datagram  rather  than  multiple  copies  of  a  datagram.  Multicast 
routing  results  in  lower  network  traffic  on  the  Internet. 

As  wireless  mobile  network  technologies  continue  to  develop,  the  mobility  and  reach 
of  telecommunication  services  must  be  independent  of  user  locations.  The  importance 
of  the  mobile  satellite  (e.g.,  low  earth  orbit  satellites  (LEO))  networks  will  increase  due 
to  the  global  visibility  and  connection. 

Currently,  multicasting  communication  service  on  the  Internet  assumes  a  static 
network  environment  instead  of  a  mobile  networks.  Moreover,  research  on  mobile 
networks  has  largely  focused  on  unicast  communications.  In  fact,  multicast 
communications  for  mobile  satellite  networks  is  an  open  research  area.  In  order  to 
implement  satellite  networks  that  satisfy  the  demand  for  a  lower  network  load  and 
mobility,  it  is  necessary  to  support  multicast  routing,  possibly  through  multicasting 
Internet  Protocol  (IP)  [ThoOl]. 
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1.2  Problem 


The  purpose  of  this  research  is  to  determine  the  effectiveness  of  various  multicast 
routing  protocols  in  LEO  satellite  networks.  LEO  satellite  systems  have  mobile 
network  topologies  and  this  dynamic  topology  makes  data  routing  difficult.  In  the 
mobile  network  research  community,  the  problem  of  implementing  IP  has  focused  on  the 
“nomadic  hosts”  and  “ad-hoc  networks”  [ThoOl],  In  the  nomadic  hosts  scenario, 
mobile  IP  supports  mobile  hosts  on  a  network  with  fixed  routers  and  topology.  In 
Mobile  Ad  hoc  Networks  (MANETs),  each  mobile  node  operates  both  as  a  host  and  a 
router.  The  application  of  these  two  models  to  a  dynamic  satellite  constellation  provides 
a  realistic  multicast  routing  scenario  for  LEO  satellite  networks.  This  research 
simulates  two  multicast  protocols  under  a  nomadic  hosts  scenario  and  an  ad-hoc  network 
scenario. 

1.3  Summary  of  Current  Knowledge 

This  section  introduces  some  standard  multicast  model  and  routing  protocols.  The 
mobile  IP  protocol  is  then  examined.  Current  mobile  multicast  techniques  are  discussed 
as  applied  to  nomadic  hosts  and  ad-hoc  networks.  Finally,  mobile  satellite  networks  are 
discussed  focusing  on  how  information  is  routed  via  intersatellite  links. 

1.3.1  The  IP  Multicast  model  and  routing  protocols 

Stephen  Deering  [Dee89]  proposed  a  standard  multicast  model  for  the  Internet 
protocol,  in  Request  For  Comment  (RFC)  1 1 12.  RFC  1112  specifies  the  host  extension 
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to  support  multicasting.  This  model  has  three  characteristics,  “IP-style  semantics”, 
“Open  groups”,  and  “Dynamic  groups”  [ThoOl].  IP  multicasting  transmits  an  IP 
datagram  to  a  host  group.  A  multicast  router  then  distributes  a  datagram  to  destination 
hosts.  This  multicast  communications  implies  that  source  nodes  know  the  multicast 
host  group  address  to  send  datagrams,  conversely  multicast  destination  hosts  in  the  group 
need  to  know  the  host  group  address  in  order  to  subscribe  to  them.  A  multicast  router 
must  keep  track  of  group  membership  infonnation  to  deliver  a  datagram.  In  order  to 
accomplish  this,  an  IP  address  space  and  group  management  mechanism  is  required. 
The  address  space  defines  multicast  host  group  addresses  as  a  Class  D  IP  address.  A 
class  D  address  uses  the  entire  32  bits  allocated  for  addressing  and  has  “1110”  as  its 
highest  order  bits.  The  remaining  28-bits  are  called  “multicast  host  group  address” 
ranging  from  224.0.0.0  to  239.255.255.255.  The  Internet  Group  Management  Protocol 
(IGMP)  provides  the  group  management  mechanism.  According  to  Deering,  “IGMP 
protocol  is  used  by  hosts  to  report  their  host  group  memberships  to  any  immediately 
neighboring  multicast  routers”  [Dee89].  The  routers  also  use  IGMP  to  discover  which 
host  groups  have  members  on  their  attached  local  networks  [Dee89]. 

Most  existing  multicast  protocols  can  be  categorized  into  source-based  and  core-based 
multicast  tree  routing  protocols  according  to  their  routing  architecture  [WaHOO],  A 
source-based  multicast  routing  tree  is  rooted  at  a  source  node  and  connects  to  every 
destination  node  of  the  multicast  group.  The  Distance  Vector  Multicast  Routing 
Protocol  (DVMRP),  Protocol  Independent  Multicast  Dense  Mode  (PIM-DM),  and 
Multicast  Open  Shortest  Path  First  (MOSPF)  protocols  are  examples  of  the  source-based 
multicast  protocols.  Core-based  multicast  routing  is  centered  on  a  core  router  (termed 
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the  Rendezvous  Point  (RP))  and  extends  to  all  group  members.  All  source  nodes  for  the 
multicast  group  share  this  tree.  The  Core-Based  Multicast  Tree  (CBT),  Protocol 
Independent  Multicast  Sparse  Mode  (PIM-SM),  and  Simple  Multicast  (SM)  are  examples 
of  core-based  multicast  protocols. 

1.3.2  Mobile  IP 

The  goal  of  the  Mobile  IP  design  is  to  pennit  a  host  to  change  its  attachment  point  to 
the  network  while  maintaining  all  existing  communications.  In  particular.  Mobile  IP 
provides  a  mechanism  for  routing  IP  packets  to  mobile  hosts  that  may  be  connected  to 
different  networks  while  keeping  their  permanent  IP  address  [Sol98] .  As  the  Mobile  IP 
name  implies,  its  purpose  is  host  mobility.  The  IETF  Mobile  IP  Working  Group  (RFC 
2002)  defined  a  protocol  to  support  a  mobile  host  implementation.  In  mobile  IP,  hosts 
maintain  a  pennanent  IP  address  wherever  they  go.  Packets  are  transmitted  to  the 
pennanent  address  of  the  mobile  host,  namely  the  home  agent  address.  If  the  mobile 
host  is  not  in  the  home  network,  packets  are  encapsulated  and  forwarded  to  the  mobile 
host’s  new  address  (foreign  agent).  When  the  mobile  host  is  at  a  foreign  network,  it 
must  register  its  new  care-of-address  with  its  home  agent.  Using  these  mechanisms,  a 
mobile  host  can  continue  to  communicate. 

1.3.3  Mobile  Multicast 

It  is  becoming  evident  that  the  Internet  must  support  mobile  nodes  that  are  nomadic 
or  “roaming”.  In  this  scenario,  a  roaming  host  may  be  connected  through  various 
means  to  the  Internet  other  than  its  well-known  fixed-address  domain  space  [ThoOl]. 
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The  Internet  Engineering  Task  Force  (IETF)  introduced  a  method  of  multicasting  routing 
support  for  mobile  hosts.  This  mechanism  has  been  developed  to  provide  the  same 
connectivity  for  mobile  hosts  a  remote  networks  as  when  they  are  connected  to  their 
home  network.  This  method  supports  nomadic  node  models  and  proposed  two  multicast 
support  options.  The  first  method  is  a  remote  subscription  and  the  second  is  a  bi¬ 
directional  tunneling  [Per96a]. 

Another  mobile  node  model  is  Mobile  Ad  hoc  Networks  (MANETs),  which  is  an 
autonomous  system  of  mobile  wireless  hosts.  Each  mobile  node  operates  both  as  a  host 
and  a  router.  According  to  S.  J.  Lee  “Ad  hoc  network  is  a  dynamically  re-configurable 
wireless  network  with  no  fixed  infrastructure  or  central  administration”  [LeSOO]. 
Various  multicast  routing  protocols  have  been  proposed  for  Ad-hoc  networks.  These 
protocols  can  be  classified  into  two  categories:  tree-based  protocols  (e.g.,  AMRoute, 
AMRIS)  and  mesh-based  protocols  (e.g.,  ODMRP)  [LeSOO]. 

1.3.4  Mobile  Satellite  INTERNET 

A  typical  geostationary  satellite  (GEOS)  is  located  at  an  orbital  altitude  of  36,000  km 
and  orbits  in  the  equatorial  plane.  This  orbital  location  results  in  large  information 
propagation  delays  and  limited  coverage  above  ±75  degrees  latitude.  The 
communication  latency  between  two  earth  stations  connected  by  a  GEOS  is  a 
considerable  barrier  to  achieve  interactive  TCP/IP  mechanism.  Therefore,  non- 
geostationary-orbit  (e.g.,  Low  Earth  Orbit)  satellite  networks  have  been  proposed  as  a 
TCP/IP  compatible  network  solution.  Low-Earth-Orbit  (LEO)  satellite  systems  operate 
at  altitudes  ranging  from  700  km  to  1500  km  [Jam98].  This  altitude  results  in  a  much 
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lower  propagation  delay  compared  to  GEOS  systems.  However,  a  LEO  satellite’s 
footprint  is  much  smaller  than  that  of  a  GEOS.  A  constellation  of  many  LEO  satellites 
is  required  to  cover  the  whole  earth  surface.  This  increases  the  complexity  of  the 
system  relative  to  GEO  systems. 

The  small  footprint  of  LEO  satellites  does  not  usually  cover  all  network  ground 
stations  at  once.  In  order  to  exchange  datagrams  as  well  as  route  information  via  LEO 
satellite  constellation  networks,  inter-satellite  links  are  necessary  [Jam98].  These  Inter- 
Satellite  Links  (ISLs)  are  constantly  changing  since  LEO  satellite  locations  are  not  fixed. 
This  dynamic  characteristic  can  easily  causes  looping  problems  between  nodes.  That  is, 
a  packet  may  not  reach  its  destination  and  simply  be  transferred  among  the  satellites. 

1.4  Scope 

The  scope  of  this  research  is  limited  to  the  simulation  and  perfonnance  evaluation  of 
two  protocols  for  LEO  multicast  satellite  networks:  the  On  Demand  Multicast  Routing 
Protocol  (ODMRP)  and  the  Distance  Vector  Multicast  Routing  Protocol  (DVMRP). 
ODMRP  is  an  ad-hoc  network  protocol.  DVMRP  is  a  nomadic  host  protocol.  Thomas 
[ThoOl]  compared  the  performance  of  ODMRP  and  DVMRP  under  various  group 
memberships,  densities  and  loading  levels  as  well  as  in  the  presence  of  satellite  failures. 
This  research  expands  upon  Thomas’  research.  Thomas  reduced  the  size  of  group 
membership  density  for  the  sake  of  simulation  time,  which  limited  its  generality.  This 
research  increases  group  membership  density.  These  two  protocols  are  also  subjected  to 
more  severe  satellite  failure  conditions.  Failures  in  multiple  satellites  expose  how 
robust  the  protocols  are  to  satellite  failure  conditions. 
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1.5  Approach/Methodology 


When  evaluating  a  computer  system’s  performance,  three  possible  methods  can  be 
used:  analytical  modeling,  simulation,  and  measurement  [Jai9 1  ] .  Each  of  the  above 
methods  is  considered  as  a  possible  evaluation  technique  to  support  this  research. 
According  to  Jain,  “Measurements  are  possible  only  if  something  similar  to  the  proposed 
system  already  exists”  [Jai91].  Since  there  does  not  exist  a  LEOS  system  to  measure 
data  from,  this  technique  is  not  a  viable  option  for  this  research 

The  second  evaluation  technique  is  analytical  modeling.  Analytical  modeling 
techniques  typically  provide  low  accuracy  because  of  simplifying  assumptions  necessary 
to  make  the  mathematics  tractable  [Jai9 1  ].  Because  of  the  dynamic  nature  of  the  system 
under  test  and  the  low  level  of  accuracy,  analytical  modeling  is  not  used  for  this  research. 
Consequently,  this  method  of  evaluation  is  excluded. 

Simulation  is  chosen  as  the  technique  to  evaluate  the  performance  of  multicasting 
communications  for  mobile  satellite  networks.  Simulation  models  relieve  some  of  the 
limiting  assumptions  associated  with  analytical  modeling  and  can  produce  results  that 
more  closely  approximate  the  performance  of  actual  systems  [Jai9 1  ] . 

1.6  Materials  and  Equipment 

The  Optimized  Network  Engineering  Tools  (OPNET)  Modeler  8.0  is  used  for  the 
modeling  and  simulation  tool  for  this  research.  OPNET  Modeler  has  a  hierarchical 
structure  that  consists  of  network,  node,  and  process  models.  The  lowest  level,  the 
process  model  is  structured  as  a  finite  state  machine  (FSM)  and  uses  C  or  C++  code  to 
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supplement  existing  library  modules.  For  the  satellite  constellation  design,  Satellite 
Tool  Kit  (STK)  4.0  by  Analytical  graphics  is  used.  OPNET  can  import  satellite 
constellation  data  created  in  STK  to  build  a  network  model. 

1.7  Summary 

This  chapter  presents  an  overview  of  the  research  conducted.  Section  1  described 
the  research  problem  and  summarized  the  current  knowledge.  The  research  scope  and 
approach  used  to  solve  the  research  problem  and  the  research  tools  used  were  described. 

The  remaining  chapters  of  this  thesis  are  laid  out  as  follows.  Chapter  2  presents  a 
detailed  background  and  literature  review  for  satellite  systems  and  multicast 
communications.  Chapter  3  describes  the  methodology  and  simulation  model 
developed  to  support  this  investigation.  The  LEOsat  network  performance  results  are 
presented  in  Chapter  4  with  research  conclusions  and  recommendations  for  future  work 
presented  in  Chapter  5. 
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Chapter  2:  Literature  Review 


2.1  Introduction 

In  Low-Earth-Orbit  (LEO)  satellite  networks,  the  constellation  can  provide  coverage 
of  the  whole  earth.  To  support  this  “whole  earth”  coverage,  the  LEO  satellite  networks 
must  have  a  robust  routing  algorithm  to  seamlessly  route  a  datagram  to  its  destination. 
The  LEO  satellite  network  communications  are  thus  based  on  the  mobile  Internet 
Protocol  (IP).  This  review  discusses  the  mobile  IP  support  for  multicast 
communications  in  the  satellite  constellation  networks.  This  chapter  discusses  IP 
multicasting  model,  routing  algorithms,  and  protocols.  The  Mobile  IP  standard  is 
examined,  including  architectural  entities  and  the  Mobile  IP  mechanism.  These  two 
standard  models  are  considered  as  possible  techniques  for  mobile  multicasting.  Current 
mobile  IP  multicasting  solutions  and  Mobile  Ad  Hoc  Networks  (MANETs)  are  described 
in  addition  to  some  routing  protocols.  Finally,  mobile  satellite  networks  are  discussed 
focusing  on  how  information  is  routed  via  intersatellite  links. 

2.2  IP  Multicast 

Multicasting  is  a  communication  mechanism  that  accepts  a  single  datagram  from  a 
source  host  and  then  delivers  the  datagram  to  a  group  of  destination  hosts.  It  improves 
unicast  (point-to-point),  the  traditional  internetworking  communication  method  for 
sending  a  datagram  from  one  sender  to  one  receiver.  When  a  unicast  system  sends  an 
individual  datagram  for  n  recipients  of  a  group,  it  sends  n  copies  of  the  datagram  using  n 
connections.  This  approach  increases  the  network  load  and  unnecessarily  replicates  the 
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datagram.  Multicasting,  on  the  other  hand,  sends  a  single  datagram  to  a  multicast  router 
that  is  connected  to  multicast  destination  hosts.  The  multicast  router  reproduces  the 
datagram  and  distributes  it  to  individual  hosts  wishing  to  receive  the  datagram  [SaMOO]. 
Multicasting  provides  a  suitable  method  for  large-scale  software  distribution,  video- 
conferencing,  or  shared  workspace  that  needs  an  efficient,  lower  network  load  solution 
[RamOO]. 

2.2.1  The  Standard  IP  Multicasting  model 

Stephen  Deering  [Dee89]  proposed  the  standard  multicast  model  for  the  Internet 
protocol  in  Request  for  Comment  (RFC)  1 1 12.  RFC  1112  specifies  the  host  extensions 
needed  to  support  multicasting  aspect.  The  model  includes 

•  IP-style  semantics 

A  source  can  send  multicast  datagrams  at  any  time  without  registration  and 
transmission  schedule.  IP  multicast  is  based  on  User  Datagram  Protocol 
(UDP),  so  datagrams  are  delivered  to  the  destination  group  with  “best-effort” 
reliability. 

•  Open  groups 

Sources  can  come  from  outside  the  group.  There  can  be  any  number  of 
sources. 


•  Dynamic  groups 

The  membership  of  a  multicast  group  is  dynamic:  that  is,  any  member  host  of  a 
group  may  join  or  leave  without  registration,  synchronization,  or  any  negotiation 
with  central  group  management  [ThoOl], 
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2.2. 1.1  Addressing 


“IP  multicasting  transmits  an  IP  datagram  to  a  ‘host  group,’  a  set  of  zero  or  more 
hosts”  [Dee89].  This  multicast  transmission  implies  that  a  source  node  need  know  the 
multicast  host  group  address  to  send  datagrams,  and  multicast  destination  hosts  in  the 
group  need  know  the  host  group  address  to  subscribe  to  it. 

Multicast  host  group  addresses  are  class  D  IP  address.  A  class  D  address  has  32  bits 
and  “1110”  as  its  highest  order  bits.  The  remaining  28-bits  are  called  the  “multicast 
host  group  address”  ranging  from  224.0.0.0  to  239.255.255.255.  Unlike  subnetting  in 
the  unicast  address,  there  is  no  structure  within  this  address  space  [Mau98]. 

The  Internet  Assigned  Numbers  Authority  (IANA)  allocates  some  of  the  Class  D 
addresses  for  special  purposes.  Multicast  host  group  addresses  ranging  from  224.0.0.1 
to  224.0.0.255  are  reserved  for  exchanging  routing  information  and  other  low-level 
topology  discovery  or  maintenance  protocols.  The  addresses  ranging  from  239.0.0.0  to 
239.255.255.255  are  reserved  for  use  within  private  networks  such  as  enterprise 
internetworks  or  intranets  [Mau98]. 

2.2. 1.2  IGMP 

Hosts  need  to  inform  the  local  router  that  they  wish  to  receive  multicast  datagrams 
sent  to  a  given  host  group.  The  Internet  Group  Management  Protocol  (IGMP)  provides 
the  mechanism  for  IP  hosts  to  report  their  host  group  memberships  to  any  immediately 
neighboring  multicast  routers.  Routers  also  use  IGMP  to  discover  which  host  groups 
have  members  on  their  attached  local  networks.  There  are  two  versions  of  IGMP: 
IGMPvl  as  described  in  RFC  1112  [Dee89]  and  IGMPv2  as  described  in  RFC  2236 
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[Fen97],  Currently,  IGMPv2  is  the  more  predominant  version  due  to  the  benefits  gained 
from  lowering  the  leave  latency  [Mau98].  Most  of  the  attributes  of  version  1  are 
included  in  version  2  with  some  enhancements. 

As  stated  above,  multicast  routers  use  IGMP  to  query  the  hosts  on  the  attached 
network  to  determine  if  they  are  members  of  a  multicast  group.  There  are  two  forms  of 
a  membership  query:  the  general  query  and  the  group-specific  query.  The  general 
query  is  used  to  leam  which  groups  have  members  on  an  attached  network.  The  group- 
specific  query  is  used  to  leam  if  a  particular  group  has  any  members  on  an  attached 
network  [Fen97].  On  startup,  the  router  with  the  lowest  IP  address  is  elected  to  transmit 
a  general  query  to  the  all-systems  multicast  group  (224.0.0. 1)  with  a  Time  To  Live  (TTL) 
set  to  1.  The  TTL  setting  ensures  that  the  queries  are  not  transmitted  to  other 
subnetworks.  A  host  that  receives  an  IGMP  query  sends  a  membership  report  to  the 
groups  which  the  host  belongs. 

Hosts  do  not  send  membership  reports  when  leaving  a  group.  In  IGMPvl,  if  no 
report  is  transmitted  after  several  queries  from  a  group  member,  the  router  assumes  there 
is  no  member  node  in  the  multicast  group  and  stops  forwarding  multicast  datagrams. 
This  can  result  in  the  long  latencies.  In  IGMPv2,  on  the  other  hand,  when  the  last  host 
leaves  a  multicast  group,  it  sends  a  leave-group  message  to  the  all-routers  multicast  group 
(224.0.0.2).  Using  this  mechanism,  a  router  can  immediately  determine  that  there  are  no 
more  hosts  in  the  multicast  group.  As  [Fen97]  states,  “When  a  router  receives  a  leave 
group  message  from  a  host,  it  sends  group-specific  queries ”,  to  determine  whether  or  not 
the  host  was  the  last  group  member. 
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2.2.2  Multicast  Routing  Algorithms 


Several  routing  algorithms  have  been  proposed  to  ensure  that  multicast  datagrams  are 
routed  throughout  internetworks.  These  algorithms  can  be  used  in  implementing 
multicast  routing  protocols. 

2.2.2. 1  Reverse  Path  Broadcasting 

Reverse  Path  Broadcast  (RPB)  was  developed  in  the  1970s  to  provide  a  network-layer 
broadcast  service.  The  RPB  algorithm  is  the  basis  of  Reverse  Path  Multicast  (RPM). 
Using  this  algorithm,  a  router  receives  a  datagram  from  a  source,  it  examines  whether  the 
link  to  the  source  is  the  shortest  path  or  not.  If  the  incoming  link  is  the  shortest  link,  a 
router  forwards  the  datagram  on  all  links  except  the  incoming  link.  If  the  datagram  did 
not  arrive  on  the  shortest  link,  then  the  datagram  is  discarded. 

RPB  is  an  efficient  way  to  deliver  a  multicast  datagram  on  the  shortest  path  from  the 
source  to  the  destination  group.  However,  RPB  is  a  broadcast  delivery  algorithm. 
Multicast  group  membership  is  not  a  factor  when  forwarding  datagrams  from  a  source. 

2.2. 2.2  Truncated  Reverse  Path  Broadcasting 

Truncated  Reverse  Path  Broadcasting  (TRPB)  is  an  improvement  of  RPB  using  IGMP 
information.  IGMP  provides  group  membership  information  so  the  router  can 
determine  which  host  groups  have  members  on  their  attached  local  subnetworks.  If  the 
subnets  do  not  have  any  member  hosts  for  a  given  destination  group,  the  router  does  not 
forward  the  datagram  to  the  subnets.  Thus,  the  router  can  truncate  the  delivery  path  and 
eliminate  unnecessary  loads.  However,  TRPB  reduces  only  unneeded  datagrams  on 
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uninterested  subnets.  TRPB  does  not  consider  group  membership  information  when 
forwarding  datagrams  to  downstream  routers.  TRPB  only  considers  the  group 
membership  infonnation  in  the  subnetworks  [Mau98]. 

2.2. 2. 3  Reverse  Path  Multicasting 

Reverse  Path  Multicasting  (RPM)  is  an  enhancement  to  the  RPB  and  TRPB 
algorithms.  RPM  sends  a  datagram  along  the  shortest  links  from  the  source  if  the  links 
lead  to  active  members  of  the  destination  group.  The  first  packet  is  broadcast  to  all 
multicast  routers  as  in  TRPB.  When  the  packet  reaches  a  multicast  router  with  no 
members  on  local  subnetworks,  a  prune  message  is  generated  and  sent  back  to  the  source. 
Prune  messages  cascade  hop-by-hop  back  to  the  source  unless  they  meet  an  active 
multicast  delivery  tree.  The  prune  messages  contain  an  age  field  that  is  deleted 
periodically  to  remove  outdated  information.  Therefore,  broadcasting  and  pruning  are 
repeated  periodically.  Using  this  age  field,  new  members  cannot  be  added  until  the  next 
broadcasting  and  pruning  cycle.  When  a  member  of  a  new  group  appears  on  a  particular 
link,  the  adjacent  router  sends  a  graft  message  to  its  parent  router.  This  process 
continues  until  the  subtree  has  been  grafted  back  to  the  active  multicast  delivery  tree 
[Mau98], 

The  RPM  process  has  a  lack  of  scalability  for  many  active  members.  Periodic 
broadcasts  result  in  wasted  bandwidth  until  updated  prune  messages  are  created. 
Additionally,  every  router  in  RPM  must  keep  track  of  forwarding  table  entries  or  prune 
information  [Mau98],  These  drawbacks  result  in  RPM  scaling  poorly  as  the  number  of 
active  sources  and  groups  increase. 
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2.2. 2.4  Core-Based  Trees 


Core  Based  Trees  (CBT)  has  been  developed  to  address  the  limitations  of  RPM.  Due 
to  its  use  of  a  shared  delivery  tree,  CBT  scales  better  than  RPM.  CBT  constructs  a 
single  distribution  tree  for  each  group  to  forward  the  multicast  datagram  of  a  particular 
group.  A  core  router  is  chosen  to  be  a  center  for  delivering  a  multicast  datagram  to  the 
group.  All  multicast  datagrams  are  forwarded  to  the  core  router  using  the  unicast 
method  and  are  then  distributed  to  the  local  router.  A  host  that  wants  to  join  a  group 
sends  a  membership  report  to  its  local  router  by  IGMP.  When  a  local  router  receives  this 
report,  it  sends  Join  Request  messages  to  the  next  hop  on  the  shortest  link  towards  the 
group’s  core  router.  Join  Acknowledgement  messages  are  then  sent  back  to  the 
corresponding  local  router  by  the  core  or  an  on-tree  router.  Upon  receiving  an 
acknowledgement,  the  local  router  can  deliver  datagrams  to  a  new  group  membership 
host  [Bal97]. 

A  CBT  multicast  tree  is  maintained  by  each  downstream  router.  The  downstream 
router  sends  a  CBT  “keep-alive”  message  (. Echo-Request )  to  its  upstream  router 
periodically.  The  receipt  of  a  keep-alive  message  over  a  child  interface  result  in  an 
Echo-Reply  response.  If  the  response  does  not  occur,  the  router  sends  a  Quit- 
Notification  message  to  its  parent  router,  and  also  sends  a  Flush-Tree  message  over  each 
downstream  interface  for  the  corresponding  group.  If  the  local  router  has  no  member  or 
downstream  on-tree  router,  the  router  sends  a  Quit-Notification  message  to  its  parent 
router  and  removes  the  forwarding  cache  [WahOO]. 

A  router  using  a  shared  CBT  tree  has  current  information  for  every  active  group  (i.e., 
per  tree)  rather  than  information  for  every  active  (source,  group)  pair  like  RPM.  This 


15 


decreases  the  size  of  multicast  routing  tables  at  the  router.  However,  this  shared 
multicast  tree  can  result  in  the  concentration  of  all  the  source’s  traffic  on  a  single  link 
[SamOO], 

2.2.3  Multicast  Routing  Protocols 

Most  existing  multicast  protocols  can  be  categorized  into  source-based  and  core- 
based  multicast  tree  routing  protocols  based  on  tree  construction  [WaHOO].  The 
following  subsections  discuss  representative  routing  protocols  for  multicast  applications. 

2.2.3. 1  Source-Based  Multicast  Tree  Routing 

A  source-based  multicast  tree  is  rooted  at  a  source  node  and  connects  to  every 
destination  node  of  the  multicast  group.  The  source  node  transmits  a  datagram  to  every 
member  of  the  group  via  the  links  of  a  multicast  tree.  The  following  three  protocols  are 
examples  of  source-based  multicast  protocols: 

2.2. 3. 1.1  Distance  Vector  Multicast  Routing  Protocol 

Distance  Vector  Multicast  Routing  Protocol  (DVMRP)  implements  the  RPM 
protocol.  DVMRP  was  first  derived  from  the  Routing  Information  Protocol  (RIP)  with 
TRPB.  Based  on  RPM,  DVMRP  employs  a  prune  message  to  delete  the  leaf  network 
without  a  member  host.  Each  DVMRP  router  then  updates  the  forwarding  table 
accordingly.  The  DVMRP  also  uses  the  RPM  graft  message  to  cancel  the  previously 
received  prune  message  if  a  new  host  wants  to  join  the  leaf  network.  This  mechanism 
quickly  returns  a  formerly  pruned  leaf  network  to  an  active  delivery  tree. 
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DVMRP  maintains  a  metric.  The  metric  indicates  the  routing  cost  of  the  link  and  is 
used  for  choosing  the  reverse  shortest  path  tree.  For  example,  if  a  particular  router’s 
metric  (router  A)  is  less  than  the  other  router’s  metric  (router  B),  router  A  is  chosen  as  the 
dominant  router  and  forward  datagrams  from  the  source  subnetworks,  while  router  B 
discards  datagrams  from  the  source.  When  both  routers  A  and  B  have  the  same  metric, 
the  router  with  the  lower  IP  address  becomes  the  dominant  router  [Mau97]. 

2.2.3. 1.2  Protocol  Independent  Multicast  DM 

Protocol  Independent  Multicast  Dense  Mode  (PIM-DM)  is  also  based  on  the  RPM 
protocol  like  the  DVMRP.  However,  there  are  two  differences  between  PIM-DM  and 
DVMRP.  The  first  is  that  PIM-DM  uses  whatever  unicast  routing  table  is  available, 
while  DVMRP  retains  its  own  routing  table  (i.e.,  Routing  Information  Protocol)  to  check 
reverse  path  forwarding.  PIM-DM  simply  employs  the  existing  unicast  routing  table 
and  is  thus  independent  of  any  specific  routing  protocol.  The  second  difference  is  that 
PIM-DM  forwards  multicast  packets  on  all  non-incoming  interfaces  unless  prune 
messages  occur.  DVMRP  determines  the  downstream  routers  that  reach  the  source, 
therefore  avoid  sending  unnecessary  packets.  PIM-DM  is  designed  to  be  independent  of 
any  unicast  routing  protocol  and  avoids  the  complexity  of  using  its  own  routing  table  but 
trades  off  excess  datagram  duplications  [Mau97]. 

2.2.3. 1.3  Multicat  OSPF 

Multicast  Open  Shortest  Path  First  (MOSPF)  is  an  extension  to  the  Open  Shortest 
Path  First  (OSPF)  algorithm.  OSPF  is  a  unicast  routing  protocol  that  is  used  in 
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Autonomous  System  (AS).  The  OSPF  keeps  the  topological  and  state  information  of 
the  AS,  namely  the  link-state  database  that  is  constructed  using  Link  State 
Advertisements  (LSAs).  A  router  calculates  the  shortest  path  for  any  router  employing 
LSAs. 

The  MOSPF  adds  a  new  OSPF  LSA  called  the  group  membership  LSA  to  maintain 
group  membership  information.  A  router  in  MOSPF  distributes  group  membership 
information  by  flooding  the  group  membership  LSA  throughout  the  AS.  When  a  router 
receives  multicast  datagrams,  it  computes  the  shortest  path  using  Dijkstra’s  algorithm 
[May94]. 

2. 2. 3. 2  Core-Based  Multicast  Tree  Routing 

A  tree  is  centered  on  a  core  router  or  Rendezvous  Point  (RP)  and  constructed  to  all 
the  group  members.  All  source  nodes  for  the  multicast  group  share  this  tree,  while  a 
source-based  multicast  tree  is  used  for  each  source.  In  a  wide  area  multicasting 
network,  a  core-based  multicast  tree  offers  better  scalability  than  a  source-based  multicast 
tree  [ChW98].  Two  core-based  multicast  tree  routing  protocols  are  discussed  below. 

2.2. 3. 2.1  Protocol  Independent  Multicast  Sparse  Mode  (PIM-SM) 

Protocol  Independent  Multicast  Sparse  Mode  (PIM-SM)  uses  any  existing  unicast 
routing  tables  like  PIM-DM.  Tree  construction,  however,  is  not  like  PIM-DM.  It  is 
based  on  CBT  multicast  algorithms.  As  stated  above,  CBT  has  the  disadvantage  of 
traffic  concentration  and  a  single  point  of  failure.  DVMRP  employs  a  pruned  Reverse 
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Shortest  Path  Tree  (RSPT)  and  has  the  drawback  that  it  must  broadcast  the  first  packet. 
PIM-SM  has  been  proposed  to  overcome  these  shortcomings. 

The  router  with  an  active  group  member  constructs  a  multicast  tree  toward  the 
group’s  RP  to  meet  the  sources.  Explicit  PIM-SM  Join  Messages,  like  CBT,  are  also 
sent  to  the  RP  through  intennediate  routers  to  make  a  forwarding  state.  Thus,  every 
router  knows  how  to  route  multicast  datagrams  to  the  designated  RPs  for  a  given 
multicast  group.  Unlike  CBT  that  suffers  from  the  limitation  of  a  single  point  of  failure, 
the  RPs  in  PIM-SM  are  discovered  and  maintained  by  a  bootstrap  protocol  [Mau97]. 
When  a  source  transmits  its  first  packet  to  a  multicast  group,  the  source’s  local  router 
encapsulates  the  PIM-SM  Register  Messages  with  the  data  to  the  RP  for  that  group. 
Upon  receiving  this  message,  the  RP  sends  a  PIM-SM  Join  Message  to  the  source’s  local 
router.  After  establishing  this  initial  forwarding  state,  the  RP  can  receive  regular 
multicast  datagrams  without  encapsulation  [Mau97]. 

PIM-SM  can  switch  to  the  source-based  Reverse  Shortest  Path  Tree  (RSPT) 
algorithm  if  a  high  data  rate  from  a  source  occurs  and  exceeds  a  predefined  threshold  data 
rate.  The  source-based  trees  may  be  well  suited  for  high  data  rate  sources  [SamOO].  A 
leaf  router  sends  a  PIM  Join  Message  toward  the  source  to  create  the  source-based  tree, 
while  conventional  source-based  tree  algorithms  (i.e.,  DVMRP,  PIM-DM)  broadcast 
initial  packets.  When  a  source  router  receives  the  Join  Message,  the  source-based  tree  is 
active. 
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2.2. 3. 2.2  Simple  Multicast  (SM) 


Simple  Multicast  (SM)  is  similar  to  PIM-SM  except  in  how  it  resolves  the  multicast 
address  allocation  problem.  SM  employs  the  identifier  of  a  multicast  group  that  has  the 
8-byte  combination  of  a  core  node  C,  and  the  multicast  address  M.  However,  M  does 
not  have  to  be  a  unique  across  the  Internet  as  in  conventional  IP  multicast,  but  must  be 
unique  per  C.  Every  core  node  C  in  the  Internet  can  be  assigned  the  full  28  bits 
multicast  address.  This  process  lessens  the  complexity  and  coordination  of  unique 
multicast  addresses  across  the  Internet  [Per98], 

2.3  Mobile  IP 

Mobile  IP  is  designed  to  pennit  a  host  to  change  its  point  of  attachment  from  one 
network  to  another  while  maintaining  existing  communications.  This  network  may  be  a 
wireless  network  with  limited  bandwidth  and  higher  bit  error  rates  than  wired  networks. 
Particularly,  Mobile  IP  provides  a  mechanism  for  routing  IP  datagrams  to  mobile  hosts 
that  may  be  connected  to  other  networks  while  keeping  their  permanent  IP  address 
[Sol98].  As  the  Mobile  IP  name  implies,  its  purpose  is  host  mobility.  The  IETF 
Mobile  IP  Working  Group  (RFC  2002)  defined  Mobile  IP  to  support  a  mobile  routing 
implementation. 

2.3.1  Mobile  IP  architectural  entities 

Mobile  IP,  RFC  2002,  introduces  new  functional  entities  to  support  its  mobility 
protocols.  These  entities  are  the 
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•  Mobile  node 

A  host  or  router  that  changes  its  point  of  attachment  from  one  network  or  subnet 
to  another.  A  mobile  host  may  maintain  communications  at  any  location  without 
changing  its  pennanent  IP  address. 


•  Home  agent 

This  is  a  router  on  a  mobile  host’s  home  network.  The  home  agent  maintains  the 
mobile  host’s  current  location  (i.e.,  care-of-address)  and  tunnels  a  datagram  for 
delivery  to  the  mobile  node. 

•  Foreign  agent 

This  is  a  router  on  a  mobile  node’s  remote  network.  The  foreign  agent  helps  a 
mobile  host  to  notify  its  home  agent  of  its  current  care-of-address.  The  foreign 
agent  detunnels  and  delivers  datagrams  to  the  mobile  hosts  that  were  tunneled  by  the 
mobile  node’s  home  agent.  For  datagram  generated  by  a  mobile  host,  the  foreign 
agent  may  serve  as  a  default  router  [Per96a]. 

2.3.2  IP-in-IP  Tunneling 

IP-in-IP  tunneling  was  proposed  to  deliver  IP  packets  to  a  mobile  host  using  mobile 
IP.  IP-in-IP  tunneling  implies  that  an  IP  packet  is  encapsulated  within  another  IP  packet 
and  then  decapsulated  at  an  intermediate  router.  In  the  general  tunneling  case,  two  main 
functional  nodes  are  necessary.  These  are  an  encapsulator  node  and  a  decapsulator 
node.  When  a  packet  is  sent  to  a  mobile  host,  an  encapsulator  node  employed  by  the 
home  agent  encapsulates  the  original  IP  packet  within  another  IP  packet  containing  a 
decapsulator  node  address.  The  decapsulator  node  simply  decapsulates  the  original  IP 
packet  and  transmits  it  to  its  final  mobile  hosts  using  standard  IP  routing  methods 
[Per96b]. 
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2.3.3  Mobile  IP  overview 


Mobile  IP  provides  two  main  services  to  support  a  host’s  mobility:  agent  discovery, 
and  registration  [Per96a]. 

In  agent  discovery,  home  agent  and  foreign  agent  periodically  advertise  their 
availability  on  a  current  attached  link  via  an  Agent  Advertisement  message.  A  mobile 
host  may  solicit  an  Agent  Advertisement  message  from  any  local  agents  via  Agent 
Solicitation  messages. 

Once  a  mobile  host  receives  an  Agent  Advertisement  message,  it  may  register  its 
current  location  state.  The  location  state  can  be  either  a  mobile  host  on  a  home  network 
or  on  a  foreign  network.  If  the  mobile  host  is  located  on  its  home  network,  it  operates  as 
a  non-mobile  host.  A  mobile  host  returning  to  its  home  network  from  being  registered 
elsewhere,  deregisters  with  its  home  agent  by  exchanging  of  Registration  Request  and 
Registration  Reply  messages.  If  a  mobile  host  is  on  a  foreign  network,  it  acquires  a 
care-of-address  on  the  foreign  network.  This  care-of  address  can  be  either  a  foreign 
agent  care-of-address  or  a  co-located  care-of-address.  In  the  case  of  a  foreign  agent 
care-of  address  case,  a  mobile  host  sends  the  Registration  Request  to  the  foreign  agent. 
The  foreign  agent  examines  the  request  and  then  relays  it  to  the  home  agent.  A 
Registration  Reply  is  sent  back  to  the  foreign  agent  from  the  home  agent  after  validating 
the  Registration  Request.  Finally,  the  foreign  agent  relays  a  Registration  Reply  to  the 
mobile  host.  In  this  mode,  the  foreign  agent  IP  address  operates  as  the  care-of-address 
that  is  also  the  tunneling  end  point.  This  means  the  foreign  agent  decapsulates  packets 
tunneled  by  the  home  agent  to  the  mobile  host’s  care-of-address  and  send  them  to  the 
mobile  host.  This  mode  is  preferred  because  many  mobile  hosts  can  use  the  same  care- 
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of  address  and  thus  overcome  the  IPv4  address  space  limitation  [Per96a].  In  the  co¬ 
located  care-of  address  mode,  the  registration  process  is  similar  to  the  foreign  agent  care- 
of-address  case  except  that  a  foreign  agent  in  not  involved.  In  other  words,  a  mobile 
host  exchanges  the  Registration  Request  and  Reply  directly  with  the  home  agent.  In  this 
case,  the  mobile  host  IP  address  works  as  the  care-of-address  and  serves  as  the  tunneling 
endpoint. 

2.4  Mobile  Multicast 

Hosts  in  a  mobile  network  can  move  arbitrarily  and  unpredictably.  Moreover, 
bandwidth  limitation  is  an  important  design  constraint  in  a  mobile  wireless  network 
topology.  Multicasting  allows  for  efficient  use  of  available  bandwidth  in  mobile 
wireless  networks  since  it  employs  one-to-many  communications  instead  of  multiple 
point-to-point  communications.  However,  the  implementation  of  multicast  services  to 
mobile  wireless  networks  is  still  a  challenging  problem.  For  instance,  all  existing 
multicast  routing  protocols  (e.g.,  DVMRP,  MOSPF,  CBT,  PIM)  assume  stationary 
multicast  hosts  when  creating  a  multicast  distribution  tree  [ChW98], 

Any  consideration  of  mobility  must  consider  the  nomadic  mobile  node  problem 
[ThoOl].  In  this  scenario,  a  roaming  host  may  be  connected  through  various  means  to 
the  network  other  than  the  well-known  fixed-address  domain  space  [Cor99]. 

Another  mobile  node  model  is  Mobile  Ad  hoc  Networks  (MANETs),  an  autonomous 
system  of  mobile  wireless  hosts.  Each  mobile  node  operates  both  as  a  host  and  a  router. 
Ad  hoc  networks  are  dynamically  re-configurable  wireless  networks  that  have  no  fixed 
infrastructure  [Cor99]. 
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2.4.1  Mobile  IP  (nomadic)  Multicasting 


In  IP  multicast,  the  group  address  and  the  source  IP  address  play  an  important  role  in 
a  packet  routing.  A  source  host  must  have  the  network  ID  of  its  IP  address  that  is  same 
as  the  network  ID  of  the  home  network.  That  is,  the  source  host  must  be  connected  to 
its  home  network  to  achieve  multicasting  service  [Sol98],  This  is  a  problem  for  mobile 
hosts  that  are  connected  to  a  foreign  network.  The  IETF’s  Mobile  IP  introduces  the 
method  of  multicast  routing  support  for  mobile  hosts  [Per96a],  This  mechanism  has 
been  developed  to  provide  the  same  connectivity  for  mobile  hosts  as  when  they  are 
connected  to  their  home  network.  This  method  supports  nomadic  node  models  and  has 
two  multicast  support  options.  The  first  method  is  remote  subscription,  the  second  is  bi¬ 
directional  tunneling. 

2.4. 1.1  Remote  Subscription 

In  a  remote  subscription,  a  mobile  host  must  re-subscribe  to  its  multicast  group  upon 
entering  a  new  foreign  network.  The  foreign  router  must  act  as  a  multicast  router  and  be 
added  to  the  multicast  tree.  This  option  assumes  that  at  least  one  multicast  router  is 
present  on  the  foreign  network. 

When  a  mobile  host  located  at  a  foreign  network  sends  a  datagram,  it  cannot  use  its 
home  network  address  as  the  source  IP  address.  A  mobile  host  using  the  Remote 
Subscription  method  uses  its  co-located  care-of-address  as  the  source  IP  address.  When 
a  mobile  host  wants  to  receive  a  multicast  datagram,  it  is  required  to  join  a  multicast 
group  via  IGMP  host  membership  reports  on  the  foreign  network  router.  Thus,  this 
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option  assumes  that  at  least  one  multicast  router  is  available  on  the  foreign  network 
[Per96a]. 

The  main  advantage  of  this  is  that  the  multicast  datagram  is  delivered  on  the  shortest 
path.  However,  if  a  mobile  host  moves  frequently,  it  must  frequently  switch  its 
subscription.  This  tree  reconstruction  cost  is  undesirable.  A  multicast  datagram  can  be 
lost  due  to  a  subscription  set  up  time  [ChW98], 

2.4. 1.2  Bi-directional  Tunneling 

Bi-directional  tunneling  is  another  option  to  provide  mobile  multicasting.  A  mobile 
host  may  join  groups  via  bi-directional  tunneling  to  its  home  agent  that  is  assumed  to  be  a 
multicast  router.  This  means  that  the  transmission  and  reception  of  multicast  datagrams 
happens  through  the  home  agent. 

When  a  mobile  host  wishes  to  receive  a  multicast  datagram,  it  tunnels  IGMP  messages 
to  its  home  agent.  The  home  agent  adds  the  mobile  host  to  the  multicast  tree  and 
tunnels  multicast  datagrams  back  to  the  mobile  host.  The  home  agent  packet  tunneling 
is  based  on  whether  the  mobile  host  is  using  a  foreign  agent  care-of-address  or  a  co¬ 
located  care-of-address.  If  the  mobile  node  is  using  a  co-located  address,  the  home 
agent  should  tunnel  the  packets  to  this  address.  Otherwise,  the  home  agent  must  first 
encapsulate  the  packets  inside  a  unicast  datagram,  and  tunnel  the  unicast  datagram  to  the 
foreign  agent.  This  double  encapsulation  allows  the  foreign  agent  to  determine  which 
mobile  host  should  receive  the  datagram  after  decapsulated.  To  send  a  multicast 
datagram  to  a  multicast  group,  the  datagram  is  tunneled  to  its  home  agent.  This 
tunneling  means  the  multicast  datagrams  are  encapsulated  with  a  unicast  header  with  the 
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mobile  host’s  home  address.  The  mobile  host  must  use  its  home  address  as  the  source 


IP  address  [Per96a], 

The  main  disadvantage  of  bi-directional  tunneling  is  convergence.  This  means  that 
when  multiple  home  agents  have  mobile  hosts  belonging  to  the  same  multicast  group  at 
the  same  foreign  network,  each  home  agent  tunnels  a  copy  of  multicast  datagrams  to  the 
foreign  agent.  The  foreign  agent  decapsulates  and  delivers  multicast  datagrams  to  the 
mobile  hosts.  The  duplicated  copies  of  the  multicast  datagram  will  arrive  at  the  mobile 
hosts  [ChW98]. 

2.4.2  Mobile  Ad  Hoc  Network  (MANET)  Multicasting 

Multicasting  protocols  used  in  static  networks  (DVMRP,  MOSPF,  CBT,  PIM)  are  not 
adequate  for  ad  hoc  networks.  “These  protocols  do  not  perform  well  in  ad  hoc  networks 
because  multicast  tree  structures  are  fragile  and  must  be  readjusted  as  connectivity 
changes”  [LeSOO].  Various  multicast  protocols  are  proposed  for  ad  hoc  networks. 
These  protocols  are  classified  into  two  categories:  a  tree-based  protocol  (e.g.,  AMRoute, 
AMRIS)  and  a  mesh-based  protocol  (e.g.,  ODMRP). 

2.4.2. 1  Ad  Hoc  Multicast  Routing  (AMRoute) 

AMRoute  [BoL98]  is  a  tree-based  protocol.  It  employs  user-multicast  trees  and 
dynamic  logical  cores.  However,  these  logical  cores  are  not  a  central  point  for  the  data 
distribution  as  in  CBT  and  PIM-SM.  The  cores  are  responsible  for  discovering  new 
group  members,  as  well  as  creating  and  maintaining  the  multicast  tree.  The  user- 
multicast  tree  is  created  by  a  bi-directional  unicast  tunneling  between  multicast  group 
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members  only.  Additionally,  the  bi-directional  tunnels  constructed  between  neighbor 
nodes  fonn  mesh  links. 

These  mesh  links  mean  tree  configurations  need  not  change  due  to  network  changes. 
This  mechanism  improves  AMRoute  robustness.  Another  advantage  is  that  processing 
and  storage  is  needed  only  on  membership  nodes  since  non-membership  nodes  are 
strictly  excluded  from  the  user-multicast  tree  [BoL98]. 

2.4. 2.2  Ad  Hoc  Multicast  Routing  Protocol  Utilizing  Increasing  id  numbers  (AMRIS) 

AMRIS  [WuT98]  constructs  a  shared  tree  using  increasing  node  identification- 
numbers.  Each  node  within  a  multicast  session  must  have  an  assigned  number,  the 
multicast  session  member  ID  (msm-id).  A  shared  multicast  tree  is  rooted  at  a  particular 
node  called  Smallest-ID  node  (Sid)  that  has  the  smallest  msm-id. 

The  Sid  initiates  a  multicast  session  by  broadcasting  a  New-Session  packet  to  its 
surrounding  neighbors.  All  nodes  receiving  the  New-Session  packet  then  calculate  their 
own  msm-ids  using  hop  counts  from  the  session  initiator.  Each  node  sends  a  one-hop 
broadcast  (i.e.,  Multicast  Beacon)  to  update  neighboring  nodes.  The  Multicast  Beacon 
message  includes  multicast  state  information  such  as  msm-ids.  Thus,  the  msm-id 
increases  in  numerical  value  as  a  function  of  hops  from  the  Sid.  A  node  can  join  a 
multicast  session  by  sending  a  Join-Req  to  a  potential  parent  node.  The  msm-id  of  the 
requesting  node  must  be  smaller  than  that  of  the  potential  parent  node. 

The  major  advantage  of  MRIS  is  that  nodes  can  recover  a  broken  link  quickly  using 
one  multicast  beacon  period.  Moreover,  the  recovery  process  is  executed  locally 
without  central  control  [WuT98]. 
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2.4. 2. 3  On-Demand  Multicast  Routing  Protocol  (ODMRP) 


ODMRP  is  a  mesh-based  multicast  routing  protocol  and  uses  “a  forwarding  group 
concept  (i.e.,  subset  of  nodes  forwards  the  multicast  packets  via  scoped  flooding)  ” 
[BaLOO].  It  is  an  on-demand  procedure  where  routes  are  built  on  request. 

If  a  multicast  sender  has  a  multicast  packet  to  send,  it  establishes  a  multicast  route 
and  refreshes  group  membership  by  sending  a  Join  Query  message  periodically.  This 
message  advertises  a  multicast  membership.  Upon  receiving  the  Join  Query  messages, 
a  multicast  receiver  generates  and  broadcasts  a  Join  Reply  to  its  neighbor  nodes.  The 
Receiving  a  Join  Reply  means  a  node  realize  whether  it  is  on  the  path  to  the  source.  If  it 
is,  it  will  be  the  part  of  a  forwarding  group.  Each  forwarding  group  member  propagates 
the  Join  Reply  until  it  reaches  the  multicast  source  via  the  shortest  path.  This 
mechanism  creates  the  path  between  pairs  (sender,  receiver)  and  forms  a  mesh  of  nodes 
(the  forwarding  group).  The  meshes  of  nodes  overcome  many  drawbacks  in  mobile 
wireless  networks  such  as  intermittent  connectivity  and  traffic  concentration.  [BaLOO]. 

2.5  Mobile  Satellite  Internet 

As  wireless  mobile  network  technologies  develop,  the  mobility  and  reach  of  the 
telecommunication  services  are  becoming  independent  of  locations.  The  importance  of 
satellite  networks  will  increase  due  to  the  global  visibility  and  the  importance  of 
telecommunications. 

A  geostationary  satellite  (GEOS)  is  located  at  36,000  km  altitude  over  the  equator. 
This  results  in  high-propagation  delays  and  limited  coverage  above  ±75  latitude  degrees. 
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The  communication  latency  between  two  earth  stations  connected  by  a  GEOS  is  a 
considerable  constraint  achieving  an  interactive  TCP/IP  mechanism.  Therefore,  non- 
geostationary-orbit  satellite  networks  have  been  proposed  as  a  TCP/IP  compatible 
network  solution.  Low  Earth  Orbit  (LEO)  satellite  systems  operate  at  altitudes  ranging 
from  700  km  to  1500  km  [Jam98].  This  results  in  a  considerably  lower  propagation 
delay.  However,  a  LEO  satellite’s  communications  footprint  is  much  smaller  than  that 
of  a  GEOS.  A  LEO  satellite  does  not  stay  in  a  fixed  position.  A  constellation  of  many 
LEO  satellites  is  required  to  cover  the  whole  earth  surface.  This  increases  the 
complexity  of  the  system  relative  to  GEO  systems. 

The  small  footprint  of  a  LEO  satellite  does  not  usually  cover  all  ground  stations  at 
once.  In  order  to  exchange  a  datagram  as  well  as  route  information  via  a  LEO  satellite 
network,  establishing  intersatellite  links  is  necessary  [Jam98].  Inter-Satellite  Links 
(ISL’s)  are  still  a  challenging  problem  and  directly  impacts  the  ad-hoc  routing  protocol 
environment  [ThoOl], 

2.5.1  Inter-Satellite  Links  (ISL’S) 

Since  LEO  satellites  do  not  remain  in  a  fixed  location,  inter-satellite  links  between 
satellites  are  constantly  changing.  This  characteristic  can  easily  causes  a  loop  problem 
between  nodes.  In  other  words,  a  packet  may  not  ever  reach  its  destination  and  simply 
circulate  around  in  the  network.  To  solve  this  problem,  Pratt  [Pra99]  researched 
dynamic  routing  algorithms  in  LEO  satellite  systems  compared  the  Extended  Bellman 
Ford  (EXBF)  and  Darting  algorithms. 
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The  EXBF  [ChR89]  is  based  on  the  conventional  Bellman-Ford  (BF)  algorithm  and 
includes  some  enhancements  to  address  packets  circulating  around  the  network. 
EXBF  eliminates  this  issue  in  the  BF  algorithm  by  maintaining  simple  paths  to  a  node 
and  updating  the  paths  to  selected  neighbors.  This  results  in  reducing  the  long 
convergence  time  [Pra99]. 

The  Darting  algorithm  was  developed  to  reduce  the  high  overhead  associated  with 
the  flooding  type  algorithms  [TsM95].  The  algorithm  postpones  “update”  message 
transmission  until  needed.  Darting  uses  two  different  mechanisms  to  update  a  routing 
table.  One  mechanism  updates  downstream  nodes  and  the  other  updates  upstream 
nodes.  Downstream  updating  embeds  recent  local  topology  changes  into  outgoing 
data  packets  which  are  propagated  to  successor  nodes.  Nodes  update  their  routing 
table  and  passes  updates  along  the  data  path.  If  there  is  a  discrepancy  in  the  topology 
between  the  current  nodes,  an  immediate  predecessor  node  updates  upstream  nodes. 
[Pra99]. 

2.6  Conclusion 

This  chapter  presents  the  current  state  of  IP  multicast,  including  address  allocation 
and  IGMP.  Multicast  routing  protocols  are  classified  in  two  categories  source-based, 
core-based  and  were  developed  from  various  multicast  routing  algorithms.  Current 
developments  in  the  mobile  IP  were  introduced.  Multicast  for  Mobile  IP  discussed 
nomadic  multicasting  and  MANETs.  Finally,  a  mobile  satellite  Internet  was  examined 
focusing  on  Inter- Satellite  Links. 
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In  mobile  satellite  Internet,  the  need  for  robust  routing  algorithms  increase,  since  the 
mobile  node  moves  constantly.  Additionally,  multicasting  is  increasingly  required  to 
save  limited  network  bandwidth  in  the  wireless  environment.  Multicasting  in  the 
mobile  satellite  networks  is  an  extremely  challenging  problem  and  efficient  solutions  are 
currently  unknown.  This  research  examines  the  efficiency  of  some  multicast  routing 
algorithms  for  a  mobile  satellite  networks. 
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Chapter  3:  Methodology 


3.1  Introduction 

This  chapter  presents  the  methodology  used  during  this  research.  Section  3.2 
defines  system  boundaries  including  satellite  specifications,  protocol  selection  and  the 
scope  of  the  system  investigation.  Section  3.3  presents  and  describes  the  performance 
metrics  used  to  evaluate  the  system.  Section  3.4  presents  system  and  workload 
parameters.  Sections  3.5  and  3.6  describe  system  factors  that  were  varied  in  terms  of 
users  and  failure  satellites.  In  section  3.7,  the  experimental  design  is  presented. 
Section  3.8  concludes  with  a  description  of  the  verification  and  validation  techniques 
used  to  support  this  research. 

3.2  System  Boundary 

3.2.1  Satellite  Specifications 

Previous  research  examined  the  perfonnance  of  Low  Earth  Orbit  satellite  networks 
[Fos98,  Pra99,  ThoOl].  These  efforts  chose  the  now  bankrupt  Iridium  constellation  as 
the  framework  for  investigation.  The  previous  efforts  chose  Iridium  based  on  its 
uniqueness  of  design  and  also  due  to  its  applicability  to  military  operations.  This 
research  is  also  based  on  the  Iridium  constellation  in  order  to  compare  results  with  the 
previous  work  using  the  same  conditions  and  assumptions. 

The  Iridium  constellation,  as  proposed,  consists  of  66  satellites  operating  at  an  orbital 
altitude  of  780  km.  Each  orbital  plane  contains  11  satellites  in  a  polar  orbit  with  an 
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inclination  angle  of  90°  relative  to  the  equatorial  plane.  To  maintain  whole-earth 
coverage,  six  orbital  planes  are  required.  Co-rotating  planes  are  separated  by  31.6 
degrees  and  counter-rotating  planes  are  separated  22  degrees  [Rod95].  This 
constellation  requires  Inter-Satellite  Links  (ISLs)  to  transfer  data.  Each  satellite  has 
links  to  four  adjacent  satellites:  forward-aft  (in  the  same  orbital  plane),  west-east  (in 
adjacent  orbital  planes)  [Jam98], 

The  footprint  of  satellite  is  critical,  in  terms  of  user  number  per  satellite.  Due  to  the 
low  780km  altitude,  each  satellite  has  a  relatively  small  coverage  area.  Thomas  [ThoOl] 
calculates  a  maximum  communication  coverage  radius  of  2436  km  using  Pythagorean’s 
theorem  and  assumes  48  spot  beams  per  satellite.  Each  spot  can  support  80  users 
[ThoOl],  Section  3.5  discusses  the  number  of  users  in  more  detail. 

The  data  rate  of  the  ISLs  and  up-down  link  is  2.5  gigabits  per  second  [ThoOl].  In 
particular,  2.5  Gbps  up-down  links  enable  multiple  users  to  access  to  a  single  satellite. 

3.2.2  Multicasting  Routing  Protocols 

Thomas  [ThoOl]  chose  to  implement  the  Distance  Vector  Multicast  Routing  Protocol 
(DVMRP)  and  the  On  Demand  Multicast  Routing  Protocol  (ODMRP)  to  compare  the 
performance  in  this  Iridium  satellite  constellation.  DVMRP  use  its  own  routing  table  to 
build  a  multicast  tree  while  ODMRP  creates  mesh-based  multicast  trees.  When 
DVMRP  builds  a  multicast  tree,  it  requires  less  overhead  than  ODMRP.  In  terms  of 
bandwidth  usage,  DVMRP  has  the  advantage.  However,  ODMRP  creates  a  more 
reliable  multicast  tree  due  to  its  mesh-based  structure.  Because  of  this  mesh-based 
structure,  ODMRP  is  more  robust  in  a  satellite  failure  environment.  These  two 
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protocols  are  also  used  in  this  research  expanding  the  analysis  to  include  more  ground 
station  users  and  more  severe  satellite  failure  conditions. 


3.2.3  Mobile  IP  Boundary 


Figure  1  Sample  One,  Two,  Three  and  Four  Satellite  Dispersal  [ThoOl] 
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Mobile  IP  has  two  multicast  support  options.  The  first  is  remote  subscription  and 
the  second  is  bi-directional  tunneling.  These  options  define  the  relationship  between  a 
home  agent  and  a  foreign  agent  in  support  of  multicasting  in  mobile  nodes.  In  the 
Iridium  satellite  constellation,  it  is  important  to  be  able  to  locate  the  home  agent  and  a 
foreign  agent  to  support  mobile  nodes.  Thomas  designed  the  LEO  satellite  network 
considering  possible  agent  locations.  In  his  model,  satellites  having  a  routing  protocol 
processor  transfer  the  datagram.  These  datagrams  originate  from  ground  stations. 
Therefore,  it  is  natural  to  place  the  foreign  agent  on  a  satellite  in  the  ground  node’s  view 
[ThoOl].  The  home  agent  thus  can  be  placed  on  the  ground  station.  According  to  the 
bi-directional  tunneling  method,  this  makes  sense  since  the  transmission  and  reception  of 
multicast  datagrams  are  controlled  through  the  home  agent.  However,  it  is  also  possible 
to  put  the  home  agent  on  a  satellite  [ThoOl].  Figure  1  shows  possible  arrangements  of 
foreign  agents  and  home  agents  when  the  home  agents  exist  in  satellites. 

3.2.4  Ad  hoc  network  Boundary 

ODMRP  is  used  as  an  ad  hoc  network  protocol.  A  critical  design  issue  is  to  the  ad- 
hoc  network  boundary.  Thomas  [ThoOl]  detennined  that  the  ad  hoc  boundary  includes 
both  the  satellite  constellation  and  the  ground  stations.  If  the  ad  hoc  network  boundary 
only  contains  the  satellite  constellation,  the  ground  stations  have  to  register  and  deregister 
with  the  satellites.  This  registration  mechanism  makes  ODMRP  like  any  other  routing 
protocol.  Simply  put,  “Utilizing  ODMRP  as  simply  a  routing  protocol  instead  of  an  ad 
hoc  manager  is  a  waste  of  the  overhead  put  into  ODMRP  to  handle  the  ad  hoc  aspect” 
[ThoOl],  This  research  follows  Thomas’s  ad  hoc  boundary. 
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3.3  Performance  metrics 


The  performance  metrics  gathered  in  the  simulation  are  the  received-to-sent  ratio, 
mean  delay,  and  the  ratio  of  effective  data  bits  sent  on  the  network  to  overhead  bits  sent 
on  the  network  ( data-to-overhead  ratio).  These  metrics  come  from  Thomas’  research  to 
measure  the  same  outcomes  under  the  different  scenarios. 

The  received-to-sent  ratio  is  “The  total  number  of  packets  sent  by  all  multicast 
sources  multiplied  by  the  number  of  multicast  receivers.  This  number  is  divided  into 
the  total  number  of  packets  received  uniquely  by  all  receivers”  [ThoOl].  This  ratio 
shows  how  many  packets  are  correctly  delivered  from  a  source  to  a  destination  (e.g., 
quality  of  service). 

Mean  delay  indicates  how  long  it  takes  to  deliver  datagrams  through  the  overall 
network.  LEO  satellite  systems  operating  at  altitudes  of  780  km  can  provide  whole- 
earth  coverage  as  do  GEOS.  Even  so,  propagation  delay  cannot  be  overlooked. 
Additionally,  the  mean  delay  is  more  reliable  than  hop  count  or  hop  ratio  since  the 
distance  of  inter- satellite  links  are  not  equally  distributed  [ThoOl], 

The  ratio  of  effective  data  bits  sent  on  the  network  to  overhead  bits  sent  on  the 
network  is  another  outcome.  This  ratio  reports  the  number  of  overhead  bits  required  to 
deliver  the  effective  data  bits.  Data  bits  are  defined  as  “bits  that  are  successfully 
transmitted  from  source  to  receiver”.  Overhead  bits  are  defined  as  “all  other  information 
transmitted  over  the  system,  including  data  bits  that  do  not  reach  their  destinations” 
[ThoOl], 
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3.4  Parameters 


3.4.1  Systems 

3.4. 1.1  Queuing  model 

In  this  satellite  network  model,  the  datagrams  randomly  arrive  at  the  satellite  to  be 
serviced  and  the  satellite  uses  some  time  to  correctly  deliver  the  datagram.  The  ground 
stations  need  to  share  the  satellite  routing  resources  since  only  one  job  can  access  the 
satellite  routing  service  at  any  time.  For  this  reason,  a  queuing  model  can  be  used  to 
analyze  the  performance  of  the  satellite  networks. 

Thomas  defines  this  satellite  network  as  a  M/G/l  processor  since  it  has  a  Poisson 
arrival  process  and  the  general  distribution  of  service  times.  He  also  assumes  an  infinite 
queue  length  to  implement  the  data  networking  rather  than  voice  transmissions  [ThoOl]. 
According  to  Jain  [Jai91],  these  conditions  satisfy  the  M/G/l  system. 

In  an  M/G/l  system,  the  datagram  arrival  rate,  service  rate,  and  the  expected  total 
time  in  the  system  (in  queue  and  in  service)  need  to  be  defined.  The  channel  capacity  of 
ISLs  and  up-down  links  were  previously  defined  as  2.5  Gbits.  This  value  specifies  the 
arrival  rate  and  the  service  rate  under  the  steady-state  utilization  p.  Section  3.4.2 
discusses  this  in  more  detail. 

The  expected  total  time  in  the  system  (here  the  satellite  defines  the  system)  consists  of 
queuing  time  and  service  time.  The  service  time  includes  both  transmission  and 
processing  time  at  each  satellite.  However,  the  processing  time  can  be  ignored  because 
it  is  much  smaller  than  the  transmission  time.  Adding  these  times  to  the  propagation 
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delays  results  in  the  end-to-end  (ETE)  delay  metric.  These  delay  times  are  illustrated  in 
Figure  2 


Figure  2  ETE  Delay  metric 

where  T0  is  queuing  time  ,  Ts  is  service  time  and  Tp  is  propagation  delay. 

For  an  M/G/l  queuing  model,  the  delay  time,  in  tenns  of  T()  (queuing  time),  and 

Ts  (service  time)  can  be  detennining  using  the  Pollaczek-Khinchin  (P-K)  fonnula  [Jai9 1  ]. 
The  service  time,  Ts ,  is 

Ts  =  L/C  (1) 

where  L  is  the  length  of  the  datagram  and  C  is  the  link  capacity. 

The  queuing  time  is 

Tq=  pE[s](l  +  C/)/2(l-^)  (2) 

where  E[s]  is  the  expected  value  of  Ts,  p  is  /l  *£'[5'],  X  is  arrival  rate,  and  Cs  is 
the  coefficient  of  variation  of  the  service  time. 
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Thus,  the  expected  total  time  in  the  system  becomes 


Texp  =  T„  +  Tq  =L/C+  pE[S  ](l  +  Cs2  )/2(l  -  p) . 


(3) 


3.4. 1.2  Algorithm  flow  charts 

Multicast  algorithms  for  ODMRP,  and  DVMRP  play  a  primary  role  in  the  entire 
simulation  of  the  system.  Figure  3  and  Figure  4  show  logic  flow  for  each  protocol 
algorithms  implemented  in  the  simulation. 


Figure  3  ODMRP  Flow  Chart  [ThoOl] 

ODMRP  constructs  a  multicast  route  using  an  on-demand  procedure  (i.e.,  Join  query 
and  reply  between  source  and  receiver).  A  source  periodically  sends  a  Join  query  to  the 
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entire  network  to  update  the  routes.  When  a  multicast  receiver  receives  the  Join  query, 
it  sends  a  Join  reply  to  the  next  node  to  make  a  forwarding  group.  A  forwarding  group 
flag  is  set  if  the  next  node  is  on  the  path  to  the  source.  Therefore,  a  multicast  datagram 
can  be  transferred  through  the  forwarding  group. 


Figure  4  DVMRP  Flow  Chart  [ThoOl] 

There  are  four  possible  main  packet  flows  in  DVMRP  utilizing  the  Mobile  IP 
mechanism.  In  Figure  4,  leftmost  column  flow  shows  neighbor  discovery  advertisement 
between  satellites.  This  advertisement  mechanism  carries  out  the  neighbor  discovery 
service.  A  route  report  packet  creates  the  DVMRP  multicast  routing  table  that  performs 
a  RPF  (Reverse  Path  Forward)  check.  This  mechanism  is  based  on  Poison-Reverse 
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metrics  that  assign  an  infinite  metric  on  an  unreachable  interface  to  determine  active 
child  interfaces.  Prune  and  Graft  packets  are  used  to  update  the  routes  according  to  the 
multicast  membership  node  existence 

3.4. 1.3  Algorithm  Timing  Issues 

Thomas  conducted  pilot  studies  to  detennine  the  timing  sensitivity  of  each  protocol. 
This  study  limited  the  length  of  time  each  algorithm  ran  to  detennine  its  performance. 
Table  1  shows  the  timing  configuration  of  each  protocol.  The  timing  configuration 
plays  a  system  parameter  role  in  the  all  simulation  trials  [ThoOl], 


Table  1  Protocol  Timing  Configuration 


ODMRP 

Forwarding  Group  Timeout 

150sec 

Route  Timeout 

lOOsec 

Mobile  IP 

Time  Between  Agent  Solicitation 

2.5sec 

Registration  Request  Timeout 

5  sec 

Collocated  Address  Timeout 

lOsec 

Registration  Timeout 

5sec 

DVMRP 

Neighbor  Probe 

26sec 

Neighbor  Timeout 

91  sec 

Flash  Update 

lOsec 

Prune  Update 

5  sec 

Graft  Registration 

5  sec 

Route  Expire 

140sec 

Prune  Expire 

600sec 

3.4.2  Workload 

The  workload  is  one  of  the  most  important  values  affecting  the  throughput  of  the 
system.  The  packet  length  and  anival  rate  is  set,  so  it  does  not  exceed  the  predefined 
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link  capacity  2.5  Gbps  and  maintains  a  constant  utilization  p .  Thomas  chose  a  mean 
data  packet  size  of  376  bytes,  and  the  minimum  data  packet  size  of  44  bytes.  This 
yields  the  standard  deviation  of  375  bytes  [ThoOl], 

The  maximum  service  rate  is  the  inverse  of  the  service  time  Ts .  The  calculation  for 
the  maximum  service  rate  is  based  on  the  link  capacity  2.5  Gbps  and  a  mean  packet  size 
of  376  bytes.  Utilization,  p ,  is  calculated  by  dividing  the  datagram  arrival  rate  by  the 
system  service  rate.  In  order  to  reduce  p  to  less  than  1  so  that  the  system  is  stable,  the 
datagram  arrival  rate  must  not  exceed  the  maximum  service  rate.  This  condition  limits 
the  loading  level  as  shown  Table  2  [ThoOl], 


Table  2  Loading  Levels 


Loading  Level 

Total  Traffic  Generation  Rate 

High  (100%) 

780  pps 

Medium  (80%) 

624  pps 

Low  (50%) 

390  pps 

3.5  The  User  Number  Factors 

Ground  stations  act  in  a  user  role  in  this  model.  Ground  stations  generate  a  packet 
as  a  source  and  transmit  the  packet  to  the  satellites.  Ground  stations  also  receive 
packets  from  the  satellites.  The  number  of  users  and  their  geographic  density  affects  the 
resources  required  to  run  the  simulations  (to  be  discussed  in  more  detail  in  Section  3.8). 
Thomas  arranges  user  density  levels  into  two  classes:  sparse  and  dense.  Sparse  mode 
randomly  distributes  the  ground  stations  to  seven  urban  areas  as  shown  in  Table  3. 
Dense  mode  randomly  distributes  the  ground  stations  across  the  globe  [ThoOl], 
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Table  3  Mobile  Node  Home  Locations 


City 

Longitude 

Latitude 

Altitude 

Rio  de  Janero 

-43.22 

-22.90 

0.01 

Melbourine 

144.97 

-37.80 

0.00 

Kansas  City 

-94.59 

39.13 

0.23 

Dharan 

50.00 

27.00 

0.76 

Beijing 

116.47 

39.90 

0.18 

Berlin 

13.42 

52.53 

0.03 

Capetown 

18.37 

-33.93 

0.00 

Thomas  [ThoOl]  chose  5,  10,  and  15  users  in  ODMRP  and  5,  10,  15,  40,  60,  and  80 


users  in  DVMRP  for  group  membership  levels.  The  higher  group  membership  levels 
(40,  60,  80  users)  were  not  applied  to  the  ODMRP  scenario  due  to  computing  resource 
limitations.  However,  this  research  models  the  higher  group  membership  levels  in 
ODMRP  scenario  to  compare  the  result  with  DVMRP  scenario  under  the  same 
conditions. 


Table  4  User  Factors 


Density 

level 

The 

number  of 

users 

Protocol 

DVMRP/ODMRP 

Sparse  / 

Dense 

Distribution 

5 

One-to-Many 

Many-to-Many 

10 

One-to-Many 

Many-to-Many 

15 

One-to-Many 

Many-to-Many 

40 

N/A 

Many-to-Many 

60 

N/A 

Many-to-Many 

80 

N/A 

Many-to-Many 
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Two  different  transmission  scheme  scenarios,  one-to-many  and  many-to-many  are 
also  applied  to  this  research.  Thomas’  research  defined  these  transmission  schemes  as 
“one  to  many  (n  members,  one  sender,  n  receivers)  and  many  to  many  (n  members,  n 
senders,  n  receivers)”  [ThoOl].  Table  4  is  a  summary  of  the  user  factors  to  be 
evaluated. 

3.6  Satellite  Failure  Factors 

Satellite  failures  show  the  robustness  of  the  protocol  in  the  presence  of  a  disabled 
satellite.  Thomas  [ThoOl]  induced  the  following  satellite  failure  scenario: 

1 .  Generate  packet  from  all  senders  to  all  receivers. 

2.  Count  packet  that  traverse  each  node. 

3 .  Remove  the  satellite  that  has  the  most  number  of  packets  traversing  it. 

4.  In  case  of  a  tie,  remove  the  satellites  with  the  most  packets  destined  for  Dharan 

In  this  research,  the  satellite  failure  scenario  follows  Thomas’  algorithms  and  adds 
more  failures  to  satellites.  For  this  investigation,  1,  3,  5,  and  7  satellites  are  chosen  for 
failure  using  two  different  strategies.  The  number  of  failed  satellites  follows  Fossa’s 
research  [Fos98]  to  observe  the  perfonnance  under  the  similar  failure  conditions. 

Satellites  are  chosen  for  failure  using  this  algorithm. 

1 .  Generate  packets  from  all  senders  to  all  receivers. 

2.  Count  the  number  of  packets  that  traverse  each  satellite. 

3.  Remove  the  most  heavily  loaded  satellite  first  then  the  next,  and  so  on  until 
you  reach  the  7th  heaviest  satellite. 
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4.  In  case  of  a  tie,  remove  the  satellite  with  the  most  packets  destined  for 
Dharan. 

This  strategy  is  identical  to  Thomas’  except  for  the  increased  number  of  failed 
satellites.  On  the  other  hand,  the  second  satellite  failure  strategy  uses  a  different 
algorithm  to  determine  the  most  heavily  loaded  satellite. 

1 .  Generate  packets  from  all  senders  to  all  receivers. 

2.  Count  the  number  of  packets  that  traverse  each  satellite. 

3.  Remove  the  most  heavily  loaded  satellite.  In  case  of  a  tie,  remove  the 
satellite  with  the  most  packets  destined  for  Dharan. 

4.  Generate  packets  from  all  senders  to  all  receivers  with  the  failed  satellite 
removed. 

Repeat  steps  2  through  4  to  select  subsequent  most  heavily  loaded  satellites  (second 
through  seventh).  Table  5  describes  satellite  failure  factors  operating  under  the  two 
different  strategies. 


Table  5  Satellite  failure  factors 


Factor 

DVMRP 

ODMRP 

The  number  of  failed  satellites 

1,3,  5,  7 

1,3,  5,  7 

Group  membership  (Sparse  Mode) 

5,  10,  15  users 

5,  10,  15  users 

Traffic  Density 

50%,  80%,  100% 

20%,  50%,  80%,  100% 

Transmission  Scheme 

Many-to-Many 

Many-to-Many 
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3.7  The  Design  of  Experiments 


3.7.1  Implementation  Details 

The  Optimized  Network  Engineering  Tools  (OPNET)  Modeler  8.0  is  used  as  the 
modeling  and  simulation  tool  for  this  research.  Thomas  created  network,  node,  and 
process  simulation  models  for  DVMRP  and  ODMRP  scenarios  using  OPNET.  This 
research  follows  Thomas’  network,  node,  and  process  simulation  model  but  adds  new 
factors  to  investigate  the  new  scenarios.  Table  6  summarizes  every  factor  combination 
used  to  evaluate  the  simulation  model 

Table  6  Simulation  Factors 


High  (100%) 

Traffic  Density 

Medium  (80%) 

Low  (50%) 

Transmission  Scheme 

One-to-Many 

Many-to-Many 

Group  Density 

Sparse 

Factors 

Dense 

Satellite  Failure 

Failure  (1,3, 5, 7  failed  satellites) 

Non  failed  satellite 

Group  Membership 

Low  membership  (5,10,15  users) 

High  membership  (40,60,80  users) 

Algorithms 

DVMRP 

ODMRP 
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3.7.2  OPNET  process  model  for  the  protocols 


The  Process  Model  is  the  one  of  three  domains  in  OPNET  that  specifies  an  object  in 
the  node  model.  The  others  are  network  and  node.  Thomas  developed  the  process 
model  that  describes  DVMRP  and  ODMRP  in  an  event-driven  simulation. 


Figure  5  DVMRP  Process  Model 

Figure  5  shows  the  DVMRP  process  model.  It  consists  of  5  states:  init,  interrupt, 
process,  and  end.  The  init  state  initializes  the  process  model  and  obtains  the  value  of 
satellite  attributes  (e.g.,  the  IP  address  of  the  satellite,  DVMRP  timing  configurations  and 
so  on).  The  interrupt  state  generates  self-interrupt  events  that  occur  in  the  DVMRP  to 
satisfy  the  protocol  specifications.  The  timing  events  listed  in  Table  1  are  implemented 
using  the  interrupt  state.  The  process  state  plays  an  important  role  in  implementing 
DVMRP  protocol  shown  in  Figure  4.  Route  report,  prune,  graft,  and  neighbor  discovery 
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packet  arrivals  invoke  the  process  state.  All  three  states  transition  to  the  idle  state  when 
they  complete.  In  the  idle  state,  the  process  model  simply  waits  for  an  interrupt. 


(default) 


Figure  6  ODMRP  Process  Model 

The  ODMRP  process  model  shown  in  Figure  6  is  similar  to  DVMRP  process  model 
except  for  the  interrupt  state.  The  process _pkt  state  implements  the  ODMRP  protocol 
(Figure  3)  just  like  the  DVMRP  process  state  does.  Join  query/reply  packet  and 
multicast  packets  are  processed  according  to  the  ODMRP  algorithm.  Forwarding  group 
expiration  is  a  function  of  the  ODMRP  timing.  The  timing  is  implemented  using  self¬ 
interrupts.  If  a  self  interrupt  occurs,  forwarding  group  is  reset. 
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3.8  Verification  and  Validation 


3.8.1  Verification 

The  model  is  verified  using  OPNET’s  compiler  and  debugger.  The  first  verification 
step  uses  the  process  model  compiler.  The  compiler  checks  the  C++  code  for  errors. 
Next,  the  OPNET  debugger  (ODB)  is  used.  ODB  assists  in  resolving  simulation  errors 
(e.g.,  program  abort,  recoverable  error  etc.).  However,  even  though  the  simulation 
succeeds  in  executing  the  model,  the  result  may  not  be  representative  to  the  intended 
algorithms.  In  this  case,  the  simulation  is  modified  and  iterated  until  the  difference  is 
found. 

This  research  reuses  the  network,  node,  and  process  model  used  in  Thomas’ 
research.  Thomas’  performance  results  were  reproduced.  Figure  7  shows  the  DVMRP 
sparse  (urban)  distribution  performance  results  simulated  in  this  research  as  a  function  of 
loading  level  and  number  of  nodes. 

Plot  (a)  is  the  data  to  overhead  ratio  and  increases  in  proportion  to  the  number  of 
nodes.  This  ratio  is  statistically  similar  across  loading  levels.  As  the  number  of  nodes 
increase  in  sparse  distribution,  the  co-located  satellite  and  ground  link  efficiency 
increases  because  more  packets  are  transferred  through  the  same  link.  This  results  in  an 
increasing  data-to-overhead  ratio  according  to  the  number  of  nodes.  Plot  (b)  shows  the 
received  to  sent  ratio  trends.  This  ratio  has  the  highest  value  with  5-member  nodes 
whose  packet  collision  is  zero,  while  the  15-member  nodes  case  has  the  lowest  ratio.  In 
the  15-member  node  case,  two  to  three  ground  stations  stay  together  in  a  single  satellite 
footprint  which  results  in  packet  collision  and  lower  the  ratio.  Plot  (c)  shows  the  end-to- 
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end  delay  increasing  in  proportion  to  loading  level  as  expected.  That  is,  the  100%  link 
loading  level  produces  longer  delays  than  80%,  50%  loading  level  does.  In  the  high 
membership  scenario  (40,  60,  and  80  nodes),  the  end-to-end  delay  increases  in  proportion 
to  the  loading  level  as  well  as  the  number  of  nodes.  As  the  number  of  nodes  increase, 


additional  traffic  is  generated  resulting  in  higher  ETE  delays 


membership(number  of  node) 


-$—50%  loading  — B — 80%loading 
-A — 100%  loading 


O  —  50%  loading  — B — 80%  loading 
-A — 100%  loading 


O  — 50%  loading  — B — 80%  loading 
-A — 100%  loading 


(a) 


(b) 


(c) 


Figure  7  DVMRP  All-to-All  Full  Comparison  (Sparse  Distribution) 

Figure  8  presents  the  ODMRP  performance  result  as  a  function  of  loading  level  and 
number  of  nodes.  This  result  is  achieved  through  a  many-to-many  transmission  scheme 
and  sparse  distribution  across  seven  home  locations. 
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loading  levels(%) 
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loading  levels(%) 


5members  — ■ —  1 0members 
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(c) 


Figure  8  ODMRP  All-to-all  Low  Membership 


Plot  (a)  shows  a  data  to  overhead  ratio  whose  trend  is  similar  to  DVMRP.  In  other 
words,  the  larger  the  number  of  nodes,  the  higher  data  to  overhead  ratio  appears.  This 
result  is  for  the  same  reason  as  DVMRP,  in  which  the  co-located  satellite  and  ground  link 
efficiency  is  increasing  in  proportion  to  the  number  of  nodes.  Plot  (b)  is  the  received-to- 
sent  ratio  that  shows  a  different  trend  with  Thomas’  results.  In  Thomas’  results,  the 
received-to-sent  ratio  converges  at  higher  loading  levels  with  99.18%  to  99.66%  of  the 
packet  being  received.  Statistically,  plot  (b)  results  are  equivalent  to  Thomas’  results 
since  the  ratios  are  also  greater  than  99%  with  the  packets  being  received  regardless  of 
membership  and  loading  level.  The  data  in  Table  7  is  calculated  using  four  different 
random  number  seeds  (i.e.,  four  different  samples)  and  95%  confidence  interval.  The 
end-to-end  delay  shown  in  plot  (c)  has  a  similar  trend  as  DVMRP.  The  ratio  increases 
proportional  to  the  loading  levels  regardless  of  membership. 
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Table  7  ODMRP  All-to-all  Low  Membership  Confidence  Interval 


Membership 

Loading 
level  (%) 

Mean 

Standard 

deviation 

Confidence  Interval  (95%) 

Lower  bound 

Upper  bound 

5  nodes 

50 

0.9908 

0.0038 

0.9848 

0.9968 

80 

0.9909 

0.0045 

0.9837 

0.9981 

100 

0.9933 

0.0007 

0.9922 

0.9944 

10  nodes 

50 

0.9941 

0.0019 

0.9911 

0.9971 

80 

0.9952 

0.0004 

0.9946 

0.9959 

100 

0.9939 

0.0005 

0.9931 

0.9947 

1 5  nodes 

50 

0.9959 

0.0013 

0.9938 

0.9981 

80 

0.9942 

0.0017 

0.9914 

0.9970 

100 

0.9942 

0.0007 

0.9931 

0.9952 

3.8.2  Validation 

Validating  the  model  is  a  difficult  problem  because  there  is  no  Iridium-like  satellite 
networks  that  use  multicasting.  However,  previous  research  [ThoOl,  Pra99,  Fos98]  on 
an  Iridium-like  satellite  network  provides  a  good  guideline  to  validate  the  model. 
Additionally,  the  simulation  models  used  and  modified  in  this  research  were  already 
verified  and  validated  by  the  previous  research  [ThoOl]. 

The  previous  research  [ThoOl]  did  not  evaluate  the  higher  group  membership  levels 
(40,  60,  and  80  users)  performance  in  ODMRP  scenario  due  to  time  and  computing 
resource  limitations.  This  research  and  previous  research  used  Sun  Ultra  10 
workstations  to  execute  the  OPNET  simulations.  The  workstation’s  significant  features 
are  shown  in  Table  8. 
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Table  8  Workstation  Features 


Ultra  10  workstation 

Processor 

440-MHz  UltraSPARC-Iii,  2-MB  Ecache 

Memory 

1-GB  memory,  4-GB  swap  memory 

Performance 

17.9  SPECint95,  22.7SPECfp95 

Operating  Environment 

Solaris  8 

The  previous  research  model  ran  low  membership  (5,  10,  and  15  users)  level 
simulations  without  problems.  However,  for  high  membership  levels  (40,  60,  and  80 
users),  a  dramatic  increase  in  the  amount  of  computing  and  time  resources  was  required. 
Furthermore,  a  memory  allocation  problem  occurred  at  60-,  and  80-user  levels  during  the 
simulation.  The  reason  for  the  memory  allocation  problem  was  the  60,  and  80-user  level 
scenarios  created  an  excessive  amount  of  entities  for  transfer  through  the  66-satellite 
constellation.  This  pushed  the  Ultra  10  workstation  resources  to  its  limits.  Table  9 
shows  the  simulation  time  for  high  membership  levels.  Maximum  simulation  time  was 
set  to  2000  sec  (33min  20sec)  for  a  scenario. 


Table  9  Simulation  Time  Consuming  for  High  Membership  Levels 


40  users 

60  users 

80  users 

ODMRP 

Sparse 

mode 

Elapsed  time 

33hrs  lmin 

39hrs  20min 

29hrs  17min 

Remaining  time 

0 

22hrs  3  min 

45hrs  35min 

Simulation  time 

33min  20sec 

23min  6sec 

12  min  50  sec 

Dense 

mode 

Elapsed  time 

36hrs  4min 

40hrs  9min 

29hrs  3  min 

Remaining  time 

0 

28hr 

57hrs  40min 

Simulation  time 

3  3  min  20  sec 

19min  21  sec 

1  lmin  21  sec 

Because  of  memory  constraints,  the  60  and  80-user  scenarios  did  not  reach  the 


specified  simulation  run  time  (2000  sec).  These  scenarios  collect  partial  results  that 
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vary  the  number  of  user  and  group  densities.  However,  these  results  are  reasonable  and 
predictable  since  the  simulation  results  trend  towards  steady-state  rather  quickly. 

Figure  9  shows  the  steady-state  trends.  To  verify  the  stability,  the  worst-case  traffic 
occurrence  scenarios  are  sampled  for  ODMRP.  That  is,  the  highest  membership  and 
100%  traffic  loading  are  chosen  to  be  the  worst  simulation  case.  These  results  are 
analyzed  in  more  detail  in  Chapter  4. 

Sparse  Distribution 
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Figure  9  ODMRP  High  Membership  (80  users) 


Dense  Distribution 
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Data  to  Overhead  ratio  - Received  to  Sent  ratio 

ETE  Delay 


3.9  Summary 

This  chapter  describes  the  research  methodology  from  the  system  boundary  to 
detailed  factors.  System  boundaries  outlined  the  simulation  model  and  limited  the 
problem  scope.  Perfonnance  metrics  were  defined  to  detennine  system  performance. 
Parameters  and  factors  were  presented  describing  the  simulation  model  environment 
including  satellite  failure  scenarios.  All  experimental  design  combinations  were  used  to 
investigate  the  model.  Finally,  verification  and  validation  technique  were  discussed. 
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Chapter  4:  Results 


4.1  Introduction 

This  chapter  presents  an  analysis  of  the  simulation  results  for  each  protocol.  First, 
the  statistical  methods  are  discussed.  The  ODMRP  simulation  results  for  high 
membership  scenario  are  analyzed  in  Section  4.3.  Section  4.4  analyzes  the  satellite 
failure  scenario  of  the  ODMRP  and  DVMRP  protocols.  Comparisons  of  the  two 
protocols  are  conducted  in  Sections  4.3  and  4.4. 

4.2  Statistical  Analysis 

This  research  runs  four  simulations  using  four  different  random  seeds  to  get  sample 
performance  metric  results  for  each  scenario.  For  instance,  in  the  40-users  case  with 
high  traffic  density  (100%  loading  level),  the  ODMRP  scenario  has  four  sample  results 
for  each  performance  metric.  The  ODMRP  high  membership  scenarios  (e.g.,  60,  and  80 
users)  collect  partial  sample  results  due  to  computing  resource  constraints  as  discussed  in 
Chapter  3.  Eventually,  these  sample  results  allow  for  calculation  of  a  sample  mean  (x  ) 
and  standard  deviation  (5).  The  95%  confidence  interval  of  the  data  was  calculated 
using 

(*  - ^[i-«/2;„-i]5 /  Jn ,  x  +  t[x_al2.n_ns /yfn)  (1) 

where  x  is  the  sample  mean,  s  is  the  sample  standard  deviation,  n  is  the  sample 
size,  a  is  the  significance  level,  and  t[1_Q,/2.„_1]  is  the  (l  -a H)  -quantile  of  a  i- 

variate  with  n  -1  degrees  of  freedom.  The  100(1- a  )%  confidence  interval  uses  the  (1- 
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a  /  2  )-quantile  of  a  unit  normal  variate  ( z:_an)  if  the  number  of  samples  is  greater  than 
30. 

Sometimes,  the  simulation  results  show  mean  values  that  are  similar  across  loading  or 
membership  levels.  To  investigate  whether  the  mean  values  are  statistically  equivalent, 
the  single-factor  ANOVA  (Analysis  Of  Variance)  is  used  according  to  Devore  [Dev99]. 
This  ANOVA  examines  the  hypothesis,  H 0 ,  that  population  means  ( fli )  from  two  or 
more  samples  are  equal 


H  0:jux=ju2=---  =  iu1 


(2) 


rtnm  nnjn 

MSTr  = - -  MSE  = -  /  =  MSTr  /  MSE 

7-1  7(7-1) 


(3) 


where  MSTr  is  the  mean  square  for  treatment,  MSE  is  the  mean  square  for  error, 
SST  is  the  sum  of  squares,  SSTr  is  the  treatment  sum  of  squares,  SSE  is  the  error 
sum  of  squares,  I  is  the  number  of  populations  being  compared  and  J  is  the  number  of 
samples.  The  calculations  of  SST  SSTr  SSE  are  based  on  equation  4,  5,  6. 


®  J-  =  £  £  -  *..)2  =  £  £  *,/  -  T,x  - 

i= 1  y=l  i=\  7=1  M 


I  J 


1^2  1 


SSTr  =  2Z(X>. -x..)2  =~YjXi-  ~TrX" 

i= 1  7=1  J  i= 1  U 


SSE  =  ZZ(x,-x,)2 

i= 1  M 


To  determine  if  770  is  true  or  false,  the  F  distribution  is  used. 


(4) 

(5) 

(6) 

That  is,  if  the 


computed  value  /  is  greater  than  or  equal  to  the  critical  value  FaI_lI(J_l)  at 
significance  level  a  ,  770  is  false.  This  case  means  that  at  least  two  /./,  are  different, 
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so  H0  is  rejected.  The  single-factor  ANOVA  is  similar  to  the  student  t- test  that 
evaluates  two  sample  means’  similarity.  In  other  words,  this  technique,  with  1=2  (the 
number  of  populations  being  compared),  is  equivalent  to  the  student  /-test.  Therefore, 
the  single-factor  ANOVA  also  can  investigate  whether  two  sample  means  are  unique. 

4.3  ODMRP  High  Membership  Scenario 

In  the  ODMRP  high  membership  scenario,  three  different  numbers  of  user  (ground 
stations)  cases  were  examined  in  two  different  distribution  modes.  The  40-,  60-  and  80- 
users  are  distributed  in  sparse  and  dense  mode  configurations.  Sparse  mode  randomly 
distributes  the  ground  stations  to  seven  urban  areas.  Dense  mode  randomly  distributes 
the  ground  stations  across  the  globe.  The  many-to-many  (n  members,  n  senders,  n 
receivers)  transmission  scheme  was  implemented  so  that  every  ground  station  can  send 
and  receive  a  packet.  As  discussed  in  Section  3.8.2,  the  ODMRP  high-membership 
results  converged  to  steady-state  very  quickly.  Although  a  simulation  does  not  reach  the 
specified  simulation  run-time  (2000seconds),  these  results  are  still  valuable.  However, 
few  exceptions  show  an  increasing  trend.  These  results  are  also  analyzed  with  the 
steady-state  results  in  the  following  sections.  The  raw  data  can  be  found  in  Table  13 
and  Table  14  in  Appendix  A. 

4.3.1  Data-to-Overhead  Analysis 

The  data-to-overhead  ratios  shown  in  Figure  10  decrease  slightly  as  the  loading  level 
increases. 


57 


Random  Distribution 


Urban  Distribution 


Figure  10  ODMRP  Data-to-Overhead  In  High  Membership 


One  of  possible  reason  to  explain  this  trend  is  packet  collision  at  high  loading  level. 
According  to  Lee  [LeSOO],  flooding  packet  delivery  and  ODMRP  have  a  similar  trend 
that  the  packet  delivery  ratio  decreases  as  the  loading  level  increases.  The  reason  for 
this  is  that  flooding  and  ODMRP  both  have  a  mesh  structure  that  causes  an  increase  in 
packet  collisions  at  higher  loading  levels.  Therefore,  the  packet  delivery  ratio  will 
decrease  at  higher  loading  levels.  The  overhead  includes  the  data  bits  that  do  not  reach 
their  destinations.  Possible  colliding  packets  increase  the  overhead  amount,  which 
results  in  lowering  the  data-to-overhead  ratio  at  higher  loading  levels. 

When  users  are  randomly  distributed  across  the  globe,  a  higher  data-to-overhead  ratio 
is  seen  relative  to  the  urban  distribution.  This  trend  is  independent  of  the  loading  level. 
For  instance  in  the  60-user  case,  the  random  distribution  has  the  slightly  higher  ratio  by 
approximately  0.014  than  the  60-user  case  in  the  urban  distribution.  In  the  urban 
distribution,  the  closely  co-located  ground  stations  in  the  footprint  of  satellite  access  the 
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same  link  and  possibly  increase  the  packet  collisions.  Again,  the  overhead  due  to  packet 
collisions  decreases  the  data-to-overhead  ratio. 


4.3.2  Received-to-Sent  Analysis 

Trends  similar  to  those  observed  in  the  data-to-overhead  ratio  are  found  in  the 


received-to-sent  ratio. 


Figure  11  ODMRP  Received-to-Sent  In  High  Membership 

The  received-to-sent  ratio  is  decreasing  in  proportion  to  loading  level.  As  the 
loading  level  increases,  data  packet  collision  frequently  occurs  due  to  the  nature  of  mesh 
structure.  This  results  in  the  lowest  ratio  at  100%  loading  level.  Another  similar  trend 
is  that  the  ratio  in  random  distribution  is  greater  than  the  ratio  of  urban  distribution. 
That  is,  the  ODMRP  protocol  with  random  distribution  of  users  is  more  reliable  than  the 
urban  distribution.  This  result  may  be  due  to  packet  collisions  or  buffer  overflow.  The 
ground  stations  are  grouped  very  tightly  in  urban  locations.  Many  ground  stations 
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access  a  single  satellite  at  the  same  time,  which  may  increase  packet  collisions  and  buffer 
overflow. 

For  the  random  distribution  of  user  locations,  the  ratio  is  increasing  as  the 
membership  is  increasing.  The  80-user  case  shows  the  highest  reliability  of  packet 
delivery  among  the  three  user  cases.  The  80-users  case  has  the  largest  number  of  nodes 
that  can  become  a  member  of  the  forwarding  group.  Therefore,  the  80-user  case  has  the 
biggest  forwarding  group  that  can  provide  the  highest  packet  delivery  ratio.  This  result 
will  be  confirmed  in  Section  4.4.2.  The  higher  number  of  ground  stations  case  is  more 
reliable  under  the  satellite  failure  condition.  However,  the  urban  distribution  result  does 
not  necessarily  follow  this  trend.  The  40  and  60-user  cases  do  not  follow  the  trend  of 
increases  in  the  received-to-sent  ratio  as  membership  is  increased.  These  cases  are 
unusual  and  the  reason  for  this  behavior  has  not  been  detennined.  The  only  modeling 
difference  between  the  random  and  urban  distributions  is  that  the  ground  stations  are 
closely  co-located  at  one  site  in  urban  distribution  and  a  single  ground  station  is  located 
at  one  site  in  for  the  random  distribution  case.  This  difference  is  probably  a  factor 
leading  to  the  exceptional  trend. 

4.3.3  End-to-End  Delay  Analysis 

The  general  trend  of  the  end-to-end  delay  is  to  increase  proportional  to  the  loading 
level.  This  is  attributable  to  the  queuing  delay  at  each  satellite.  Queuing  delay  is  the 
only  variable  affecting  the  end-to-end  delay  metric  since  the  service  time  and  propagation 
delay  are  fixed  in  a  given  membership.  The  100%  loading  level  has  the  longest  queuing 
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length  and  as  a  result,  obviously,  the  longest  delay.  Figure  12  shows  the  effects  on 
delay  caused  by  increases  in  loading  levels. 
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Figure  12  ODMRP  End-to-End  Delay  In  High  Membership 


In  the  urban  distribution,  more  ground  stations  access  a  single  satellite  simultaneously 
than  for  the  random  distribution  case.  The  satellite  in  the  urban  distribution  case  has  a 
longer  queuing  length  than  the  satellite  in  the  random  distribution  case.  This  is  because 
more  ground  stations  share  the  single  satellite  routing  resource.  This  results  in  the 
longer  delay  in  the  urban  distribution  than  for  the  random  distribution. 

The  60-user  case  has  the  longest  end-to-end  delay  in  each  distribution  mode 
regardless  of  loading  level.  It  is  generally  expected  that  the  additional  users  increase  the 
end-to-end  delay  due  to  the  additional  packet  flow.  Actually,  the  80-user  case  in  the 
DVMRP  scenario  showed  the  longest  delay  in  Thomas’  research  [ThoOl],  However, 
the  ODMRP  performance  does  not  follow  this  trend.  There  is  no  conclusive  evidence 
the  delay  is  increasing  or  decreasing  in  proportion  to  the  membership  density. 
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4.3.4  The  comparison  of  ODMRP  and  DVMRP  in  High  Membership 


To  compare  the  performance  between  DVMRP  and  ODMRP  for  a  high  membership 
level,  the  random  distribution  mode  is  chosen  as  the  point  of  comparison  between 
protocols.  The  random  distribution  mode  does  not  have  the  location  argument  shown  in 
urban  mode  because  a  ground  station  is  located  at  a  single  site.  Figure  13  presents  each 
performance  result  for  the  DVMRP  and  ODMRP  high  membership  levels.  The 
DVMRP  performance  results  in  high  membership  level  are  based  on  Thomas’  research 


[ThoOl], 


— ♦ — ODMRP_40  users 
— A — ODMRP  80  users 
-  -  o  -  -  DVMRP  60  users 


— ■ — ODMRP  60  users 
-  -  o  -  -  DVMRP  40  users 
■  ■  -A  ■  ■  DVMRP  80  users 


Figure  13  Comparison  of  High  Membership  Performance  Metrics  in  Dense  Mode 

The  data-to-overhead  ratio  shows  the  largest  difference  between  the  ODMRP  and  the 
DVMRP  protocol  performance.  DVMRP  has  a  much  higher  ratio  than  ODMRP.  This 
research  defines  overhead  as  not  only  control  packet  due  to  the  protocols  but  also  any 


62 


data  packets  that  fail  to  reach  its  destination  as  well.  When  ODMRP  forwards  a  data 
packet,  it  destroys  any  duplicate  data  packets  and  data  packets  arriving  to  non-forwarding 
groups.  These  data  packets  increase  the  overhead  in  ODMRP  [ThoOl]. 

As  expected,  the  ODMRP  provides  the  higher  received-to-sent  ratio  than  the 
DVMRP.  The  mesh  structure  of  the  ODMRP  shows  higher  reliability  due  to  redundant 
paths.  However,  the  typical  source  tree  of  the  DVMRP  shows  a  lower  ratio.  This  is 
due  to  the  fact  that  as  paths  change  or  become  inoperable,  data  packets  can  be  lost.  The 
large  number  of  ground  stations  in  high  membership  level  creates  abundant  uplinks  and 
downlinks  which  increases  the  use  of  inter-satellite  links.  The  more  complicated  usage 
of  inter-satellite  link  may  cause  packet  collisions,  losses,  and  congestions  to  occur. 
ODMRP  dynamically  reconfigures  using  an  alternative  path  while  the  DVMRP  suffers 
link  breaks  at  high  membership  level.  The  reason  why  the  DVMRP  presents  the  longer 
delay  than  the  ODRMP  is  also  based  on  this  mechanism.  Packet  congestion  results  in 
longer  delays  for  DVMRP,  whereas  ODMRP  dynamically  delivers  a  data  packet  using  a 
redundant  path. 

4.4  Satellite  Failure  Scenario 

Two  different  satellite  failure  strategies  were  used  to  determine  protocol  performance 
in  the  presence  of  satellite  failures.  After  choosing  the  most  heavily  loaded  satellite  up 
to  the  seventh  one,  setting  the  time  of  the  failure  is  needed.  The  failure  time  was 
considered  as  a  parameter  in  Thomas’  research.  Thomas  investigated  three  different 
failure  starting  times  (500,  1000,  and  1500  seconds)  using  the  DVMRP  protocol  satellite 
constellation.  The  500  second  failure  starting  time  was  chosen  because  it  allowed  for 
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the  greatest  system  performance  observation  time  after  a  satellite  failure.  Ground 
stations  that  are  in  the  footprint  of  the  failed  satellite  cause  variance  in  performance. 
The  time  that  the  ground  stations  are  in  the  footprint  of  a  failure  satellite  ranged  from 
approximately  750  seconds  to  1300  seconds  [ThoOl], 


4.4.1  DVMRP  Satellite  Failure 

The  satellite  constellation  employing  DVMRP  also  examined  two  different  failure 
strategies  to  detennine  which  strategy  has  the  greatest  impact  on  performance.  The 
received-to-sent  performance  ratio  is  used  to  measure  this  impact  because  it  represents 
the  correctly  delivered  packet  ratio. 

Table  10  The  Packet  Amount  in  DVMRP  Satellite  (15  users) 


Rank 

Strategy  1 

Strategy  2 

Satellite 

Number 

The  number  of  packet 
(No  Fail) 

Satellite 

Number 

The  number  of  packet 
(1  Satellite  Fail) 

1 

40 

27585 

40 

Failed 

2 

27 

26403 

42 

27347 

3 

23 

26293 

49 

26773 

4 

42 

26081 

52 

26620 

5 

38 

25873 

27 

26470 

6 

34 

25597 

50 

25862 

7 

41 

25228 

45 

25730 

8 

18 

25058 

28 

25680 

9 

45 

24964 

18 

25412 

10 

29 

24822 

51 

25334 

11 

49 

24801 

23 

25149 

Table  10  shows  the  number  of  packets  traversing  the  most  heavily  loaded  satellites. 
This  data  is  used  to  determine  any  “hot  spots”  within  the  constellation  and  also  indicates 
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which  satellite  should  be  chosen  to  fail.  Strategy  one  examines  the  loading  data  on 
satellites  in  a  non-failure  mode  and  then  chooses  the  failed  satellites  based  on  the  non¬ 
failure  loading.  For  example,  satellite  number  40  has  the  most  packets  traversing 
through  it.  In  a  single-satellite  failure  environment,  this  would  be  the  satellite  chosen  to 
fail.  Once  this  satellite  has  been  caused  to  fail,  simulations  are  executed  again  and  the 
performance  examined.  Similarly  for  two  and  three  satellite  failures  using  strategy  one, 
satellites  numbered  27  and  23  would  then  be  failed.  The  key  aspect  to  remember  here  is 
that  the  satellites  that  will  be  chosen  to  fail  are  those  most  heavily  loaded  in  a  non-failure 
scenario.  Strategy  two  takes  a  slightly  different  approach.  Satellite  number  40  is  still 
the  most  heavily  loaded  satellite.  Failure  strategy  two  fails  satellite  number  40  (in  a 
single  failure  scenario)  and  then  re-executes  the  simulations  to  see  how  the  load  is 
redistributed  to  other  satellites.  As  shown  in  Table  10,  satellite  number  42  now  is  the 
second  most  heavily  loaded  whereas  in  scenario  one,  it  was  the  fourth  most  heavily 
loaded.  This  second  strategy  now  fails  these  newly  loaded  satellites  and  observes  the 
resulting  perfonnance  in  the  multiple  satellite  failure  environments. 

Figure  14  shows  that  strategy  one  has  a  greater  impact  on  performance  than  strategy 
two.  The  received-to-sent  ratio  results  are  shown  as  a  function  of  loading  level  in  the  5, 
10,  15  user  cases. 
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Figure  14  Effect  of  Failure  Strategy  on  DVRMP 

According  to  the  DVMRP  logic,  the  source  tree  is  created  by  choosing  the  reverse 
shortest  path  metric  to  the  source.  That  is,  the  heavily  loaded  router  (i.e.,  satellite)  has 
the  shortest  path  metric  to  the  source  or  the  lower  IP  address  in  the  case  of  tie  metrics 
[Mau97].  Another  possible  case  is  that  the  heavily  loaded  router  plays  a  common  multi¬ 
access  router  role.  Therefore,  adjacent  routers  share  this  router  to  receive  the  packets. 
The  three-satellite  combination  of  40,  27,  and  23  has  the  largest  number  of  packets 
transmitted  from  the  source  in  the  strategy  one  scenario.  These  satellites  are  chosen  as 
the  shortest  path  to  the  source  and  play  a  critical  role  in  forwarding  multicast  packets. 
When  strategy  one  is  applied  at  the  500  seconds  failure-starting  time,  these  three  satellites 
are  in  the  critical  path  to  the  source.  This  three-satellite  failure  case  allows  77.4%  of  the 
packets  sent  to  be  received  at  100%  loading  in  the  5-user  case.  This  is  4.3%  less  than 
the  three-satellite  failure  case  using  strategy  two.  In  strategy  two,  satellites  42,  and  49 
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show  the  largest  number  of  packets,  which  means  these  two  satellites  are  adjusted  to  the 
shortest  path  to  the  source  after  failing  satellite  number  40.  However,  for  the  three- 
satellite  failure  case  (i.e.,  satellite  40,  42,  and  49  fail  simultaneously)  starts  to  fail  in 
strategy  two,  satellites  42,  and  49  are  not  the  second  and  third  shortest  path  to  the  source 
as  expected.  In  other  words,  this  case  fails  satellites  42,  and  49  that  mark  the  fourth  and 
eleventh  heavily  loaded  satellites  in  strategy  one  before  satellites  42,  and  49  are  adjusted 
to  the  second  and  third  shortest  path  to  the  source.  This  result  shows  that  DVRMP  does 
not  dynamically  reroute  the  data  packets  as  connectivity  changes.  Therefore,  strategy 
two  for  the  three-satellite  failure  case  has  slightly  less  impact  than  strategy  one.  The 
following  section  presents  each  performance  metric  results  by  applying  strategy  one 
failure  scenario.  The  raw  data  can  be  found  in  Table  16,  Table  17,  and  Table  18  in 
Appendix  A. 

4.4. 1 . 1  Data-to-Overhead  Ratio  Analysis 

Figure  15  presents  the  data-to-overhead  ratio  as  a  function  of  loading  levels  and  the 
number  of  satellite  failures.  The  general  trend  of  the  data-to-overhead  ratio  is  increasing 
in  proportion  to  the  number  of  users.  The  highest  ratio  is  for  the  15  users,  100%  loading 
level,  7-satellite  failure  case,  which  transmitted  a  mean  of  0.448  bits  of  data  for  every  one 
bit  of  overhead.  The  lowest  ratio  is  the  5  users,  50%  loading  level,  1 -satellite  failure 
case,  with  a  mean  of  0.279  bits  of  data  for  every  one  bit  of  overhead. 
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Figure  15  DVMRP  Data-to-Overhead  In  Satellite  Failures 

In  Figure  15. a,  the  data-to-overhead  ratio  is  increasing  in  proportion  to  the  loading 
levels.  The  100%  loading  level  in  each  failure  case  shows  the  highest  ratio.  As  the 
loading  level  increases,  the  link  utilization  goes  higher.  Additionally,  this  overhead  in 
DVMRP  is  independent  of  the  transmitted  data  bit,  which  means  the  overhead  has  a 
relatively  constant  value  [ThoOl],  A  single-factor  ANOVA  reveals  the  statistical 
significance.  The  non-satellite  failure,  three  and  five-satellite  failure  results  are 
statistically  identical  at  any  chosen  loading  level  (at  significance  level  of  0.05).  The  one 
satellite  failure  and  seven-satellite  failure  results  are  also  statistically  identical  at  a  given 
loading  level  (at  significance  level  of  0.05).  When  comparing  the  failure  case  against 
the  non-failure  case,  the  one  and  seven-satellite  failure  cases  affect  the  network  by  a 
decrease  of  approximately  4%  in  the  data-to-overhead  ratio.  This  result  shows  that  the 
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number  of  failure  satellites  (i.e.,  worst  case  of  seven  failures)  is  not  closely  related  to  the 
reduction  in  the  data-to-overhead  ratio  of  DVMRP. 

Figure  15.b  shows  that  the  data-to-overhead  ratio  is  slightly  increasing  in  proportion 
to  the  loading  levels  like  the  5-user  case.  However,  every  satellite  failure  case  increases 
the  ratio  compared  to  the  non-failure  case  in  contrast  to  the  5-user  results.  The  highest 
ratio  occurs  at  a  100%  loading  level,  5 -satellite  failure  case.  In  this  scenario,  a  mean  of 
0.41 1  bits  of  data  was  transmitted  for  every  one  bit  of  overhead.  Again,  three  and  seven 
satellite  failure  scenario  results  are  statistically  identical  at  a  given  loading  level  (at 
significance  level  of  0.05)  by  applying  the  single-factor  ANOVA.  Comparisons  of  the 
data-to-overhead  ratio  fluctuations  in  the  failed  cases  with  the  non-fail  cases  are 
unpredictable.  However,  this  phenomenon  is  likely  attributable  to  the  sparse 
distribution  of  ground  station  (users)  across  the  seven  global  locations.  The  5-user  case 
has  ground  stations  at  five  sites.  The  10-user  case  has  two  ground  stations  at  three  sites 
and  one  ground  station  at  four  sites.  This  difference  causes  the  different  phenomenon 
between  5-user  and  10-user  cases. 

In  Figure  15.c,  the  data-to-overhead  ratio  is  not  necessarily  increasing  in  proportion  to 
the  loading  level.  The  ratio  values  are  statistically  identical  within  a  given  satellite 
failure  case  except  for  the  five  and  seven-satellite  failure  cases  indicating  the  slightly 
increasing  ratio.  This  trend  also  comes  from  the  ground  station  distribution.  The  15- 
user  case  has  two  ground  stations  at  six  sites  and  three  ground  stations  at  one  site.  The 
site  in  15-user  case  has  at  least  two  ground  stations  at  a  site,  which  contribute  to  the  high 
link  utilization  by  sharing  the  same  link.  However,  misrouted  data  packets  also  occur 
more  frequently.  Misrouted  data  packets  also  increase  overhead  because  the  overhead 
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includes  misrouted  data  packet  as  the  part  of  it  [ThoOl].  In  high  membership  level  cases 
(e.g.,  40,  60,  and  80  users)  in  Thomas’  research,  the  variance  of  data-to-overhead  ratio  is 
insignificant  across  the  loading  level.  The  non-satellite  failure,  three  and  five  satellite 
failure  results  are  statistically  identical  at  any  loading  level.  The  one  and  seven  satellite 
failure  results  are  also  statistically  identical  at  a  given  loading  level.  When  comparing 
the  failure  cases  against  the  non-failure  case,  only  the  one  and  seven  satellite  failure  case 
results  (80%  and  100%  loading  level)  affect  the  network  by  an  approximate  increase  of 
1.5%. 

4.4. 1.2  Received-to-Sent  Ratio  Analysis 


(a)  (b)  (c) 


— • — No  Fail  1  Fail  — ♦  —  3  Fail  —  -  5  Fail  ♦  7  Fail 

Figure  16  DVMRP  Received-to-Sent  In  Satellite  Failures 

Figure  16  presents  the  received-to-sent  ratio  as  a  function  of  loading  levels  and  the 
number  of  satellite  failures.  The  trend  of  ratio  values  indicates  a  horizontal  line  across 
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the  loading  levels.  In  other  words,  these  ratios  are  not  different  within  a  given  satellite 
failure  case  regardless  of  the  loading  levels.  However,  the  received-to-sent  ratio  is 
decreasing  in  proportion  to  the  number  of  satellite  failures  because  the  packets  sent  from 
the  ground  stations  are  lost.  Clearly,  when  the  ground  stations  are  in  the  footprint  of  the 
failed  satellite,  the  failed  satellite  cannot  receive  the  packets  sent  from  the  ground 
stations.  As  the  number  of  satellite  failures  increase,  so  does  the  likelihood  of  packet 
losses  due  to  ground  stations  not  being  covered  by  a  satellite. 

The  decreasing  trend  of  the  ratio  is  different  among  the  5,  10,  and  15-user  cases.  In 
the  5-user  case,  the  ratio  drops  significantly  as  the  number  of  failure  satellites  increases. 
The  lowest  ratio  marks  around  0.6  at  the  7-satellite  failure  case.  This  provides  a  36% 
difference  with  respect  to  the  non-failure  case.  However,  changes  in  perfonnance  of  the 
10-user  and  15-user  are  not  as  dramatic.  The  lowest  ratio  for  the  10-user  case  is  0.72,  or 
a  21%  decrease  from  the  non-failure  case.  Additionally,  the  non-failure  case  is 
statistically  identical  to  the  one-satellite  failure  case.  The  15-user  case  has  the  12.3% 
difference  between  the  failure  and  non-failure  cases  and  the  lowest  ratio  of  0.79.  The 
three,  five,  and  seven-satellite  failure  cases  are  statistically  identical.  Again,  the  non¬ 
failure  and  the  one-satellite  failure  cases  are  statistically  identical  in  15 -user  scenario. 
The  reason  for  this  result  is  also  based  on  the  uneven  distribution  among  the  seven 
geographic  locations.  Table  11  presents  the  received-to-sent  ratio  calculations  to 
explain  the  results  given  the  following  assumptions: 

1 .  A  ground  station  can  send  only  one  packet. 

2.  When  the  satellite  failure  occurs,  it  affects  5,  10,  or  15  ground  stations. 
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3.  The  only  one  of  seven  geographic  locations  is  in  the  footprint  of  failed 
satellite.  In  the  5-user  case,  only  one  of  five  locations  is  in  the  footprint  of 
failed  satellite. 

Table  11  Sample  DVMRP  Received-to-sent  ratio  calculation 


The  number 

of  users 

The  number 

of  sent  packet 

The  number  of 

received  packets 

Received-to- 

Sent  Ratio 

The  probability  of 

occurrence 

5  users 

5 

4 

80%(=  4/5) 

100% 

10  users 

10 

9 

90%(=  9/10) 

57%(=  4/7) 

8 

80%(=  8/10) 

43%(=  3/7) 

1 5  users 

15 

13 

87%(=  13/15) 

86%(=  6/7) 

12 

80%(=  12/15) 

14%(=  1/7) 

The  5-user  case  has  the  lowest  received-to-sent  ratio  because  one  of  five  packets  sent 


is  always  lost.  The  10-user  case  has  the  ratio  range  from  0.8  to  0.9.  The  case  where 
the  ratio  is  0.9  (one  ground  station  per  location  is  in  the  footprint  of  the  failed  satellite) 
happens  with  57%  probability.  The  other  case  (0.8  ratio)  that  two  ground  stations  are  in 
a  location  has  43%  satellite  failure  occurrence  probability.  In  the  15-user  case,  two 
ground  stations  are  at  six  locations  and  have  the  highest  probability  of  being  in  the 
footprint  of  a  failed  satellite  (86%  probability).  This  results  in  a  little  higher  ratio  than 
10-user  case. 

4.4. 1.3  End-to-End  Delay  Analysis 

Figure  17  presents  the  end-to-end  delay  as  a  function  of  loading  levels  and  the 
number  of  satellite  failures. 

The  first  trend  of  the  end-to-end  delay  is  increasing  as  the  loading  level  increases. 
This  trend  is  attributable  to  the  queuing  delay.  In  this  research,  queuing  delay  heavily 
depends  on  the  loading  level  because  the  channel  capacity  of  Inter-Satellite  Links  (ISLs) 
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has  a  fixed  value  (2.5Gps).  The  100%  loading  level  has  the  longest  queuing  length, 
which  makes  the  delay  longer  than  any  other  loading  level  queue. 


(a)  (b)  (c) 


— ♦ — No  Fail  --♦--IFail  — ♦  —  3  Fail  — ♦ —  5  Fail  —♦—7  Fail 

Figure  17  DVMRP  End-to-End  Delay  In  Satellite  Failures 

The  second  trend  is  that  the  delay  is  increasing  in  proportion  to  the  number  of  satellite 
failures.  This  is  because  as  more  satellites  fail,  more  packet  routing  is  required  to  move 
the  packets  around  the  failed  satellites.  However,  some  failure  cases  are  statistically 
similar  in  spite  of  increasing  the  number  of  failed  satellites.  In  the  5-user  case,  the 
performance  for  the  non-failure,  one,  and  three  satellite  failure  scenarios  are  statistically 
identical  at  any  chosen  loading  level  (at  significance  level  0.5).  In  the  10-user  case,  the 
five  and  seven  satellite  failure  results  are  also  statistically  identical.  In  these  cases, 
network  performance  is  not  affected  by  increasing  the  number  of  failure  satellites. 
Unlike  the  five  and  ten  user  cases,  the  15-user  case  shows  that  the  delay  does  not 
necessarily  increase  in  proportion  to  the  number  of  satellite  failures.  The  single  satellite 
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failure  scenario  is  statistically  identical  at  significance  level  0.05  to  the  three-satellite 
failure  case.  The  seven-satellite  failure  case  delay  is  greater  than  the  single  satellite 
failure  case  and  smaller  than  the  five-satellite  failure  case.  The  five-satellite  failure  case 
has  a  slightly  longer  delay  than  any  other  case.  This  is  an  unusual  result.  There  is  no 
conclusive  evidence  to  explain  the  results. 


4.4.2  ODMRP  Satellite  Failure 

Similar  to  the  strategy  perfonned  for  the  DVMRP  satellite  failure  scenario,  pilot  tests 
were  conducted  under  two  different  failure  strategies  to  find  which  strategy  impacts 
performance  the  most.  The  received-to-sent  ratio  perfonnance  metric  was  used  to 
measure  the  impact. 


Table  12  The  Packet  Amount  in  ODMRP  Satellite  (10  users) 


Rank 

Strategy  1 

Strategy  2 

Satellite 

Number 

The  number  of  packet 
(No  Fail) 

Satellite 

Number 

The  number  of  packet 
(1  Satellite  Fail) 

1 

40 

19912 

40 

Failed 

2 

29 

19900 

50 

19997 

3 

50 

19888 

24 

19968 

4 

34 

19886 

23 

19964 

5 

23 

19876 

11 

19956 

6 

11 

19862 

39 

19853 

7 

39 

19477 

29 

19838 

8 

17 

19461 

51 

19829 

21 

24 

18987 

21 

19346 

Table  12  presents  the  number  of  packet  at  each  satellite  by  applying  strategies  one 
and  two  in  the  10-user  case.  In  strategy  one,  failing  satellite  number  40  is  the  single- 
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satellite  failure  case.  Failing  satellites  29  and  50  along  with  40  is  the  three-satellite 
failure  case.  For  strategy  two,  satellites  50  and  24  are  as  the  second  and  third  heaviest 
loaded  satellites.  These  satellites  are  the  other  two  satellites  in  the  three-satellite  failure 


case.  In  contrast  to  the  DVMRP  satellite  scenario,  strategy  two  has  a  more  impact  than 


strategy  one. 
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Figure  18  Effect  of  Failure  Strategy  on  ODMRP 


In  ODMRP,  the  forwarding  group  is  responsible  for  forwarding  data  packets  between 
a  source  and  a  receiver.  The  forwarding  group  can  create  multiple  routes  because  it 
consists  of  multiple  nodes.  It  is  a  mesh  of  nodes  rather  than  a  typical  tree  structure. 
When  a  primary  path  is  broken  between  a  source  and  receiver,  the  forwarding  group  can 
provide  an  alternative  path  since  it  has  a  redundant  path  built  by  a  mesh  structure 
[BaLOO].  In  strategy  two,  the  satellites  numbered  50  and  24  are  used  as  the  alternative 
path  node  when  the  most  heavily  loaded  satellite  (number  40)  fails.  Satellite  24  was  the 
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twenty-first  most  heavily  loaded  satellite  in  strategy  one  in  now  the  third  heaviest  loaded 
satellite  in  strategy  two.  In  the  three-satellite  failure  case,  packets  that  are  supposed  to 
be  delivered  to  the  satellite  40  are  rerouted  to  the  other  failed  satellites  (i.e.,  satellites  50, 
and  24).  This  results  in  more  packet  losses  than  strategy  one  and  lowers  the  received-to- 
sent  ratio.  This  result  shows  that  the  ODRMP  can  dynamically  reroute  the  packet  using 
the  redundant  paths  rather  than  readjusting  the  route  and  minimize  the  packet  loss.  The 
following  section  presents  perfonnance  metric  results  using  strategy  two.  To  examine 
in  more  detail  the  relationship  between  the  loading  levels,  the  20%  loading  level  is  added. 
The  raw  data  can  be  found  in  Table  20,Table  21,  and  Table  22  in  Appendix  A. 

4.4.2. 1  Data-to-Overhead  Ratio  Analysis 


(a)  (b)  (c) 


No  Fail  -  - 1  Fail  — ♦  —  3  Fail  — ♦-  -  5  Fail  ♦  -7  Fail 

Figure  19  ODMRP  Data-to-Overhead  In  Satellite  Failures 
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The  general  trend  of  the  data-to-overhead  ratio  is  an  increase  in  proportion  to  the 
number  of  satellite  failures.  The  seven-satellite  failure  case  shows  the  highest  ratio  in 
each  case.  When  a  satellite  fails  to  serve  as  a  router  role,  a  data  packet  can  take  an 
alternative  path.  The  same  number  of  data  packets  is  still  delivered  to  a  destination. 
While  the  data  packets  are  rerouted,  overhead  packets  (e.g.,  Join  query  and  reply )  used  to 
create  the  mesh  structure  remain  unchanged  until  updating  is  done  by  Join  query.  When 
ODMRP  updates  the  route  state,  it  broadcasts  a  Join  Query  to  the  entire  network.  The 
receiver  that  received  the  Join  Query  starts  to  create  a  forwarding  group  by  propagating  a 
Join  Reply  to  an  available  node.  In  the  satellite  failure  case,  the  failed  satellite  that  was 
the  member  of  forwarding  group  in  the  non-failure  case  becomes  an  invalid  node.  This 
causes  a  fewer  number  of  control  packets  to  be  broadcast  to  the  network.  Therefore,  the 
smaller  forwarding  group  is  created  as  the  number  of  failed  satellites  is  increasing.  This 
results  in  a  slightly  increasing  trend  in  the  data-to-overhead  ratio. 

4.4. 2.2  Received-to-Sent  Ratio  Analysis 

The  received-to-sent  ratio  in  Figure  20  shows  a  similar  trend  to  DVMRP.  This  ratio 
also  decreases  in  proportion  to  the  number  of  satellite  failures.  When  a  ground  station  is 
in  the  footprint  of  failed  satellites,  obviously,  packets  sent  from  the  ground  stations 
cannot  reach  a  satellite.  Packet  losses  occur  more  frequently  as  the  number  of  failed 
satellites  increases 
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Figure  20  ODMRP  Received-to-Sent  In  Satellite  Failures 

This  decreasing  trend  varies  across  the  different  user  cases.  The  5-user  case  shows 
the  lowest  ratio  for  the  seven-satellite  failure  scenario.  This  ratio  is  0.756.  However, 
the  10  and  15-user  cases  still  have  greater  than  a  0.9  ratio  although  seven  satellites  have 
failed.  This  is  caused  by  differences  in  the  number  of  forwarding  groups.  This 
research  sets  the  ODMRP  boundary  to  include  the  satellite  constellation  and  the  ground 
stations.  This  boundary  can  have  ground  stations  as  the  part  of  forwarding  group 
members  that  usually  consist  of  satellite  nodes.  Therefore,  the  10  and  15 -user  cases 
have  larger  forwarding  group  members  than  the  5-user  case.  Larger  forwarding  groups 
can  create  more  redundant  paths  that  ensure  packet  delivery  with  minimum  packet  loss. 
The  largest  forwarding  group  (i.e.,  the  15-user  case)  shows  the  robust  packet  delivery  in 
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Figure  20. c.  In  this  case,  a  single  satellite  failure  does  not  affect  the  non-satellite  failure 

case.  These  cases  are  statistically  identical  at  significance  level  of  0.05 


4.4. 2. 3  End-to-End  Delay  Analysis 
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Figure  21  ODMRP  End-to-End  Delay  In  Satellite  failures 

The  general  trend  of  the  end-to-end  delay  in  the  ODMRP  failure  scenario  shows  a 
larger  delay  as  the  number  of  satellite  failures  increase.  The  data  packets  are  rerouted 
around  broken  paths  using  redundant  paths  created  by  the  ODMRP.  As  the  number  of 
failed  satellites  increase,  more  packets  are  more  frequently  rerouted  creating  longer 
delays.  However,  some  cases  do  not  show  this  dramatic  effect  by  simply  increasing  the 
number  of  failed  satellites.  For  instance,  the  five  and  seven-satellite  failure  cases  in  the 
10-user  case  are  statistically  identical  at  a  significance  level  of  0.05.  The  statistical 
similarity  is  also  observed  between  the  five  and  seven-satellite  failure  cases  in  the  15-user 
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case.  In  particular,  the  single  satellite  case  does  not  significantly  affect  the  non-failure 
scenario  for  the  15-user  case.  Figure  21.c  shows  the  almost  overlapping  line  between 
the  non-failure  and  single  satellite  failure  scenarios.  This  is  also  attributable  to  the 
redundant  paths.  The  15-user  case  has  the  largest  number  of  redundant  paths  among 
three  user  cases  that  provides  robustness  against  the  satellite  failures. 

In  the  non-failure  scenario  for  each  user  level,  the  delay  increases  slightly  as  the 
loading  level  increases.  Delay  typically  increases  in  proportion  to  the  loading  level. 
The  100%  loading  level  has  the  longer  queuing  delay  than  any  other  loading  level. 
However,  the  trend  reverses  when  a  satellite  does  not  act  in  a  node  role.  For  instance, 
the  three,  five,  and  seven-satellite  failure  scenarios  show  the  delay  increasing  as  the 
loading  level  decreases  in  every  case.  According  to  ODMRP  protocol,  ODMRP  updates 
membership  and  route  information  by  sending  Join  Query  control  packet  to  the  network. 
This  Join  Query  control  packet  is  periodically  flooded  only  if  a  sender  has  a  data  packet 
to  send.  Therefore,  the  100%  loading  level  floods  control  packets  more  frequently  than 
any  other  loading  level.  This  results  in  updating  the  route  information  more  frequently 
and  removing  the  stale  routes  created  by  the  satellite  failures.  Initially,  the  satellite 
chosen  to  fail  was  a  valid  node  because  the  failure  scenario  begins  at  500  seconds  of 
simulation  time.  The  100%  loading  level  case  updates  the  failed  satellite  information 
faster  than  any  other  loading  level  by  sending  the  control  packets  out  more  frequently. 
The  20%  loading  level  may  use  the  failed  satellite  as  a  valid  satellite  node  before 
realizing  it  became  an  invalid  satellite.  This  is  because  of  the  lack  of  immediate 
feedback  through  the  network  of  satellite  failures  (not  uncommon  in  an  actual  network). 
The  data  packet  may  not  reach  a  destination  and  circulate  around  the  network. 
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Additionally,  the  ODMRP  has  a  soft-state  to  maintain  the  multicast  group.  In  other 
words,  there  is  no  explicit  message  when  a  node  member  leaves  or  joins  the  multicast 
group.  The  route  refreshing  time  (100  seconds)  and  forwarding  group  time  out  (150 
seconds)  are  the  only  way  to  update  the  route  infonnation  unless  the  updating  control 
packet,  Join  Query,  occurs.  These  time  intervals  delay  the  route  update  and  create  the 
longer  end-to-end  delays. 

4.4.3  Protocol  Comparison 

To  compare  the  each  perfonnance  between  DVMRP  and  ODMRP,  the  5-user  case  is 
used.  The  5-user  case  does  not  have  the  location  argument.  There  is  a  ground  station 
at  a  site,  which  shows  the  even  distribution  unlike  the  10,  and  15-user  case.  The  5-user 
case  can  provide  an  absolute  comparison  condition  between  the  protocols. 

4.4.3. 1  Data-to-Overhead  Ratio  Analysis 

In  Figure  22,  DVMRP  shows  a  higher  data-to-overhead  ratio  than  ODMRP.  When  a 
particular  satellite  failure  scenario  is  applied,  each  protocol  shows  a  different  trend. 
DVMRP ’s  ratio  is  decreasing  and  ODMRP ’s  ratio  is  increasing  after  failing  a  satellite. 

ODMRP  broadcasts  fewer  control  packets  to  the  network  when  a  satellite  fails.  The 
failed  satellites  cannot  exchange  Join  query  and  Join  Reply  control  packets.  ODMRP 
has  a  soft-state  that  allows  a  multicast  source  or  a  receiver  to  stop  sending  a  control 
packet  when  they  want  to  leave  the  multicast  group  [BaLOO],  This  mechanism  creates 
fewer  control  packets.  Additionally,  lost  data  packets  created  by  a  failed  satellite  do  not 
dramatically  increase  the  overhead  because  ODMRP ’s  mesh  nodes  prevent  the  packet 
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lost.  Less  control  packets  increase  the  data-to-overhead  ratio  in  proportion  to  the 
number  of  failure  satellite. 


— ♦ — No  Fail  1  Fail  — ♦  —  3  Fail  —  -  5  Fail  ♦  7  Fail 

Figure  22  The  Data-to-Overhead  comparison  between  DVMRP  and  ODMRP 

However,  the  lost  data  packets  in  DVMRP  increase  the  overhead.  This  results  in 
decreasing  the  data-to-overhead  ratio.  Additionally,  the  ground  station  that  is  in  the 
footprint  of  failed  satellite  still  receives  the  data  packet  in  spite  of  data  packet  losses. 
To  receive  the  data  packet,  DVMRP  pays  a  cost  to  sustain  the  same  vector  data  under  the 
satellite  failure  conditions.  To  sustain  the  same  connectivity  under  the  satellite  failures, 
additional  overhead  (e.g.,  flood  and  prune  control  packets)  of  creating  a  new  tree  are 
needed. 
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4.4. 3. 2  Received-to-Sent  Ratio  Analysis 


o 

0.95 

2 

0.9 

1/T 

Q. 

0.85 

C 

0 

0.8 

( J ) 

'a) 

0.75 

Q. 

0.7 

"D 

0 

> 

0.65 

'0 

O 

0 

0.6 

0.55 

DVMRP 


- 4 - « 


80  100 
loading  levels 


O 

1.05 

ro 

CO 

1.00 

Q. 

0.95 

C 

0 

03 

0.90 

1/T 

Q. 

0.85 

~o 

0 

> 

0 

0.80 

O 

0 

0.75 

ODMRP 


50  80  100 

loading  levels(%) 


-♦ — No  Fail  1  Fail  — ♦  —  3  Fail  — ♦ —  5  Fail  —♦—7  Fail 

Figure  23  The  Received-to-Sent  Comparison  between  DVMRP  and  ODMRP 


DVMRP  and  ODMRP  show  a  similar  trend  for  the  received-to-sent  ratio.  Figure  23 
presents  the  decreasing  ratio  as  the  number  of  failure  satellite  is  increasing.  Data 
packets  transmitted  from  the  ground  stations  in  the  footprint  of  failed  satellites  are  lost. 
The  more  failure  satellites,  the  more  data  packets  are  lost.  However,  robustness  when 
satellites  failure  is  differently  observed  between  protocols.  DVMRP  has  the  lowest 
received-to-sent  ratio  at  0.6  while  ODMRP  has  the  lowest  ratio  0.76  in  the  seven-satellite 
failure  case.  This  result  shows  that  ODMRP  has  the  higher  reliability  than  DVMRP. 
The  mesh  of  nodes  in  ODMRP  provides  the  higher  received-to-sent  ratio  while  the  source 
tree  of  DVMRP  loses  the  data  packets  as  connectivity  changes. 
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4.4. 3. 3  End-to-End  Delay  Analysis 


As  the  numbers  of  satellite  failures  increase,  the  end-to-end  delay  also  increases  for 
both  DVMRP  and  ODMRP.  This  comes  from  packet  rerouting  time  caused  by  failed 
satellites.  However,  each  protocol  shows  a  different  trend  under  the  satellite  failure 
environment.  DVMRP  shows  the  increasing  delay  while  ODMRP  shows  a  decreasing 
delay  as  the  loading  level  increases.  Figure  24  shows  these  trends. 


Figure  24  The  End-to-End  Delay  Comparison  between  DVMRP  and  ODMRP 

The  source  on  demand  mechanism  in  ODMRP  may  delay  route  updating  at  lower 
loading  levels.  As  the  number  of  satellite  failures  is  increasing,  the  old  route 
information  delays  the  packet  delivery  from  a  source  to  a  receiver.  Unlike  ODMRP, 
DVMRP  satisfies  the  queuing  delay  as  the  loading  level  increase.  DVMRP  has  a  typical 
source  tree. 
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ODMRP  shows  the  dramatic  increase  in  delay  while  DVMRP  shows  a  slight  increase 
in  delay  when  a  satellite  fails.  This  result  comes  from  the  timing  configurations  based 
in  each  protocol.  Each  protocol  has  its  own  route  refresh  function  to  update  old  route 
information  when  a  satellite  fails  to  route  a  data  packet.  A  flash  update  in  DVMRP 
and  forwarding  group  time  out,  and  route  time-out  in  ODMRP  are  the  examples.  Flash 
update  is  ten  seconds,  the  forwarding  group  time-out  is  150  seconds  and  the  route  time¬ 
out  is  100  seconds.  Hence,  ODMRP  takes  the  longer  route -refreshing  interval  to  update 
old  route  infonnation  than  DVMRP.  This  results  in  dramatically  increasing  delay. 

4.5  Conclusions 

Both  protocols  display  unique  characteristics  in  the  high  membership  scenario  and 
satellite  failure  scenario.  In  the  high  membership  scenario,  ODMRP  has  advantages 
using  the  metric  of  received-to-sent  ratio  and  the  end-to-end  delay.  The  mesh-based  tree 
of  ODMRP  provides  more  reliable  packet  delivery  and  less  end-to-end  delay  than 
DVMRP  as  the  complexity  of  the  route  increases  with  a  high  number  of  users. 
However,  the  DVMRP  requires  less  overhead  than  ODMRP  by  simply  creating  a  source 
tree.  In  the  satellite  failure  scenario,  strategy  one  has  a  greater  impact  on  performance 
than  strategy  two  in  DVMRP  scenario,  whereas  strategy  two  has  a  more  severe  impact 
than  strategy  one  in  ODMRP.  These  two  different  failure  scenarios  reveal  that  DVMPR 
does  not  dynamically  configure  a  route,  whereas  ODMRP  does  when  multiple  satellites 
fail.  As  expected,  ODMRP  showed  a  higher  reliability  of  packet  delivery  than  DVMRP 
in  the  presence  of  failed  satellites.  However,  the  on-demand  procedure  and  timing 
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configuration  of  ODMRP  skew  the  end-to-end  delay  as  the  number  of  failed  satellites 
increase. 
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Chapter  5:  Conclusions 


5.1  Restatement  of  Research  Goal 

The  goal  of  this  research  was  to  expand  Thomas’  research  of  comparing  two 
multicast  protocols  for  a  LEO  multicast  satellite  network.  The  first  is  the  Distance 
Vector  Multicast  Routing  Protocol  (DVMRP)  and  the  other  is  the  On  Demand  Multicast 
Routing  Protocol  (ODMRP).  These  protocols  are  examined  under  various  simulation 
environments  (i.e.,  large  group  membership  density  and  satellite  failure  conditions). 

5.2  Research  Contributions 

Thomas  [ThoOl]  analyzed  DVMRP  and  ODMRP  in  a  LEO  satellite  constellation 
network.  Thomas’  research  was  limited  to  analyzing  small  group  membership  density 
and  a  single  satellite  failure  condition  for  verifying  the  robustness  of  a  LEO  satellite 
network.  One  of  the  most  significant  contributions  of  this  research  was  the  analysis  of  a 
LEO  satellite  network’s  robustness  against  multiple  failed  satellites.  Two  different 
algorithms  for  choosing  failed  satellites  revealed  a  characteristic  of  the  protocols  in  more 
detail  against  a  partially  broken  network.  Another  significant  result  of  this  research  was 
the  analysis  of  the  large  group  membership  density  in  a  LEO  satellite  network.  In 
particular,  a  large  group  membership  density  in  ODMRP  was  evaluated  in  order  to  show 
generality  for  group  membership  density.  These  two  significant  results  provided  a  more 
complete  assessment  of  the  Distance  Vector  Multicast  Routing  Protocol  (DVMRP)  and 
the  On  Demand  Multicast  Routing  Protocol  (ODMRP)  in  a  LEO  satellite  network. 
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5.3  Conclusions 


Each  protocol  has  its  own  advantages  and  disadvantages.  Each  protocol  can  be  a 
viable  choice  for  a  LEO  satellite  network  depending  on  the  situation. 

In  a  large  membership  density,  ODMRP  seems  a  logical  choice  regardless  of 
bandwidth  usage.  ODMRP  outperfonned  DVMRP  in  reliable  packet  delivery  and  end- 
to-end  delay  scenario.  However,  ODMRP  had  a  smaller  data-to-overhead  ratio 
(approximately  23%)  than  DVMRP.  ODMRP  requires  high  bandwidth  usage  for 
creating  mesh-based  trees. 

In  multiple  satellite  failure  conditions,  ODMRP  has  the  most  reliable  packet  delivery 
ratio.  The  ODMRP  also  increases  packet  delivery  ratio  as  the  group  membership 
increases.  However,  ODMRP  showed  an  enormous  end-to-end  delay  in  severe  satellite 
failure  condition.  In  particular,  the  end-to-end  delay  at  low  loading  levels  dramatically 
increased,  which  is  undesirable  in  real-time  communications.  In  contrast,  DVMRP 
suffered  broken  routes  and  changes  in  satellite  failure  conditions.  It  demonstrated  less 
reliable  packet  delivery  than  ODMRP  (approximately  60%  versus  76%  for  the  5 -user 
case).  DVMRP  showed  scalable  and  stable  end-to-end  delay  under  multiple  failed 
satellite  conditions. 

5.4  Future  Research 

The  OPNET  simulation  model  used  in  this  research  can  be  expanded  to  study  an 
alternate  protocol.  In  particular,  Protocol  Independent  Multicast-Dense  Mode  (PIM- 
DM)  is  a  possibility.  The  ‘Broadcast  and  Prune’  mechanism  is  used  in  the  DVMRP  and 
PIM-DM  in  order  to  create  a  multicast  tree.  However,  PIM-DM  uses  a  unicast  routing 
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table  to  check  Reverse  Path  Forwarding  (RPF)  while  DVMRP  uses  its  own  routing  table 
built  from  the  route  report  process.  PIM-DM  can  be  an  alternative  to  replace  DVMRP. 

Another  future  research  area  is  the  analysis  of  other  LEO  satellite  constellations  such 
as  Teledesic.  The  Iridium  project  used  as  the  framework  for  investigation  is  no  longer 
commercially  viable.  It  seems  impossible  to  compare  the  result  of  research  with  a  real- 
world  system.  Teledesic  is  also  a  LEO  satellite  constellation  network  utilizing  288 
satellites.  It  is  expected  to  be  in  service  in  2005.  The  study  of  multicast  routing 
algorithms  for  Teledesic  can  provide  a  realistic  evaluation  of  LEO  multicast  satellite 
networks. 
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Appendix  A.  Data  Tables 


Table  13  ODMRP,  High  Membership,  Urban  Distribution  (Sparse) 
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Table  14  ODMRP,  High  Membership,  Random  Distribution  (Dense) 
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40 

50 

0.1988 

0.0007 

0.9764 

0.0004 

0.0520 

0.0001 

80 

0.1967 

0.0004 

0.9726 

0.0002 

0.0535 

0.0000 

100 

0.1966 

0.0001 

0.9704 

0.0002 

0.0544 

0.0000 

60 

50 

0.2295 

0.0002 

0.9872 

0.0003 

0.0567 

0.0003 

80 

0.2275 

0.0003 

0.9850 

0.0010 

0.0567 

0.0001 

100 

0.2264 

0.0002 

0.9822 

0.0008 

0.0577 

0.0001 

80 

50 

0.2390 

0.0006 

0.9909 

0.0005 

0.0541 

0.0006 

80 

0.2368 

0.0004 

0.9882 

0.0003 

0.0544 

0.0004 

100 

0.2364 

0.0003 

0.9869 

0.0003 

0.0550 

0.0003 
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Table  15  DVMRP,  Received-to-Sent  Ratio,  Strategy  1  and  2 


Users 

Loading  Levels 

(%) 

Non-Satellite 

Failure 

1 -Satellite 

Failure 

3-Satellite  Failure 

Strategy  1 

Strategy  2 

X 

S 

X 

S 

X 

S 

X 

S 

5 

50 

0.9397 

0.0016 

0.8587 

0.0065 

0.7735 

0.0052 

0.8184 

0.0047 

80 

0.9404 

0.0028 

0.8542 

0.0031 

0.7726 

0.0033 

0.8137 

0.0051 

100 

0.9387 

0.0043 

0.8571 

0.0054 

0.7736 

0.0088 

0.8167 

0.0031 

10 

50 

0.9084 

0.0027 

0.9076 

0.0027 

0.8215 

0.0026 

0.8491 

0.0193 

80 

0.9087 

0.0011 

0.9070 

0.0022 

0.8223 

0.0012 

0.8577 

0.0034 

100 

0.9087 

0.0027 

0.9064 

0.0020 

0.8200 

0.0019 

0.8578 

0.0015 

15 

50 

0.9051 

0.0026 

0.9049 

0.0021 

0.7935 

0.0024 

0.8224 

0.0024 

80 

0.9030 

0.0032 

0.9049 

0.0028 

0.7918 

0.0030 

0.8221 

0.0021 

100 

0.9020 

0.0025 

0.9010 

0.0046 

0.7909 

0.0029 

0.8211 

0.0018 

Table  16  DVMRP,  Data-to-Overhead  Ratio,  Satellite  Failures 


Loading 

Non-Satellite 

1-Satellite 

3-Satellite 

5-Satellite 

7-Satellite 

Users 

Levels 

Failure 

Failure 

Failure 

Failure 

Failure 

(%) 

X 

S 

X 

S 

X 

S 

X 

S 

X 

S 

50 

0.2892 

0.0022 

0.2792 

0.0029 

0.2886 

0.0036 

0.2906 

0.0019 

0.2807 

0.0011 

5 

80 

0.2984 

0.0045 

0.2851 

0.0043 

0.2942 

0.0032 

0.2975 

0.0017 

0.2882 

0.0032 

100 

0.3098 

0.0047 

0.2965 

0.0053 

0.3032 

0.0044 

0.3063 

0.0031 

0.2967 

0.0033 

50 

0.3881 

0.0019 

0.3982 

0.0027 

0.4018 

0.0016 

0.4034 

0.0009 

0.4003 

0.0009 

10 

80 

0.3900 

0.0020 

0.3995 

0.0039 

0.4034 

0.0039 

0.4055 

0.0019 

0.4026 

0.0024 

100 

0.3928 

0.0033 

0.4037 

0.0032 

0.4068 

0.0022 

0.4108 

0.0009 

0.4067 

0.0017 

50 

0.4405 

0.0015 

0.4459 

0.0034 

0.4358 

0.0027 

0.4368 

0.0029 

0.4449 

0.0037 

15 

80 

0.4416 

0.0025 

0.4479 

0.0039 

0.4385 

0.0018 

0.4391 

0.0036 

0.4458 

0.0014 

100 

0.4397 

0.0036 

0.4473 

0.0031 

0.4373 

0.0043 

0.4428 

0.0018 

0.4481 

0.0033 
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Table  17  DVMRP,  Received-to-Sent  Ratio,  Satellite  Failures 


Loading 

Non-Satellite 

1-Satellite 

3-Satellite 

5-Satellite 

7-Satellite 

Users 

Levels 

Failure 

Failure 

Failure 

Failure 

Failure 

(%) 

X 

S 

X 

S 

X 

S 

X 

S 

X 

S 

50 

0.9397 

0.0016 

0.8587 

0.0065 

0.7735 

0.0052 

0.7184 

0.0029 

0.6002 

0.0062 

5 

80 

0.9404 

0.0028 

0.8542 

0.0031 

0.7726 

0.0033 

0.7153 

0.0061 

0.5994 

0.0022 

100 

0.9387 

0.0043 

0.8571 

0.0054 

0.7736 

0.0088 

0.7151 

0.0037 

0.5981 

0.0021 

50 

0.9084 

0.0027 

0.9076 

0.0027 

0.8215 

0.0026 

0.7873 

0.0028 

0.7209 

0.0019 

10 

80 

0.9087 

0.0011 

0.9070 

0.0022 

0.8223 

0.0012 

0.7873 

0.0013 

0.7188 

0.0035 

100 

0.9087 

0.0027 

0.9064 

0.0020 

0.8200 

0.0019 

0.7891 

0.0030 

0.7194 

0.0032 

50 

0.9051 

0.0026 

0.9049 

0.0021 

0.7935 

0.0024 

0.7953 

0.0011 

0.7960 

0.0012 

15 

80 

0.9030 

0.0032 

0.9049 

0.0028 

0.7918 

0.0030 

0.7954 

0.0008 

0.7957 

0.0021 

100 

0.9020 

0.0025 

0.9010 

0.0046 

0.7909 

0.0029 

0.7958 

0.0004 

0.7941 

0.0020 

Table  18  DVMRP,  End-to-End  Delay,  Satellite  Failures 


Loading 

Non-Satellite 

1-Satellite 

3-Satellite 

5-Satellite 

7-Satellite 

Users 

Levels 

Failure 

Failure 

Failure 

Failure 

Failure 

(%) 

X 

S 

X 

S 

X 

S 

X 

S 

X 

S 

50 

0.0680 

0.0002 

0.0679 

0.0004 

0.0683 

0.0004 

0.0697 

0.0003 

0.0705 

0.0005 

5 

80 

0.0687 

0.0004 

0.0683 

0.0004 

0.0689 

0.0003 

0.0702 

0.0003 

0.0711 

0.0002 

100 

0.0691 

0.0005 

0.0689 

0.0004 

0.0694 

0.0005 

0.0706 

0.0003 

0.0714 

0.0004 

50 

0.0656 

0.0001 

0.0682 

0.0001 

0.0689 

0.0001 

0.0696 

0.0000 

0.0697 

0.0001 

10 

80 

0.0662 

0.0001 

0.0688 

0.0001 

0.0695 

0.0001 

0.0702 

0.0001 

0.0701 

0.0002 

100 

0.0666 

0.0002 

0.0692 

0.0002 

0.0698 

0.0001 

0.0707 

0.0002 

0.0705 

0.0002 

50 

0.0683 

0.0001 

0.0709 

0.0000 

0.0707 

0.0002 

0.0714 

0.0001 

0.0711 

0.0001 

15 

80 

0.0688 

0.0001 

0.0714 

0.0001 

0.0712 

0.0000 

0.0720 

0.0001 

0.0716 

0.0000 

100 

0.0691 

0.0001 

0.0718 

0.0002 

0.0715 

0.0001 

0.0724 

0.0001 

0.0719 

0.0001 
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Table  19  ODMRP,  Received-to-Sent  Ratio,  Strategy  1  and  2 


Users 

Loading  Levels 

(%) 

Non-Satellite 

Failure 

1 -Satellite 

Failure 

3 -Satellite  Failure 

Strategy  1 

Strategy  2 

X 

S 

X 

S 

X 

S 

X 

S 

5 

50 

0.9908 

0.0038 

0.9482 

0.0041 

0.8857 

0.0101 

0.8789 

0.0108 

80 

0.9909 

0.0045 

0.9434 

0.0036 

0.9017 

0.0069 

0.8835 

0.0057 

100 

0.9933 

0.0007 

0.9504 

0.0043 

0.9033 

0.0050 

0.8855 

0.0033 

10 

50 

0.9941 

0.0019 

0.9865 

0.0017 

0.9532 

0.0015 

0.9352 

0.0016 

80 

0.9952 

0.0004 

0.9871 

0.0009 

0.9523 

0.0012 

0.9349 

0.0007 

100 

0.9939 

0.0005 

0.9863 

0.0015 

0.9507 

0.0009 

0.9322 

0.0031 

15 

50 

0.9959 

0.0013 

0.9969 

0.0002 

0.9902 

0.0005 

0.9758 

0.0005 

80 

0.9942 

0.0017 

0.9950 

0.0009 

0.9880 

0.0008 

0.9739 

0.0006 

100 

0.9942 

0.0007 

0.9944 

0.0009 

0.9864 

0.0010 

0.9720 

0.0011 

Table  20  ODMRP,  Data-to-Overhead  Ratio,  Satellite  Failures 


Loading 

Non-Satellite 

1-Satellite 

3-Satellite 

5-Satellite 

7-Satellite 

Users 

Levels 

Failure 

Failure 

Failure 

Failure 

Failure 

(%) 

X 

S 

X 

S 

X 

S 

X 

S 

X 

S 

20 

0.1381 

0.0051 

0.1414 

0.0054 

0.1483 

0.0019 

0.1521 

0.0020 

0.1566 

0.0028 

5 

50 

0.1215 

0.0032 

0.1253 

0.0029 

0.1351 

0.0026 

0.1402 

0.0039 

0.1459 

0.0027 

80 

0.1200 

0.0031 

0.1222 

0.0049 

0.1311 

0.0061 

0.1374 

0.0045 

0.1417 

0.0048 

100 

0.1201 

0.0015 

0.1279 

0.0013 

0.1309 

0.0072 

0.1384 

0.0045 

0.1395 

0.0057 

20 

0.1449 

0.0013 

0.1453 

0.0017 

0.1523 

0.0020 

0.1575 

0.0024 

0.1663 

0.0029 

10 

50 

0.1307 

0.0009 

0.1314 

0.0010 

0.1399 

0.0007 

0.1438 

0.0010 

0.1540 

0.0012 

80 

0.1276 

0.0006 

0.1291 

0.0011 

0.1378 

0.0008 

0.1429 

0.0014 

0.1525 

0.0013 

100 

0.1277 

0.0009 

0.1297 

0.0008 

0.1418 

0.0009 

0.1483 

0.0008 

0.1596 

0.0015 

20 

0.1542 

0.0027 

0.1555 

0.0020 

0.1591 

0.0018 

0.1627 

0.0024 

0.1665 

0.0009 

15 

50 

0.1404 

0.0008 

0.1417 

0.0007 

0.1463 

0.0005 

0.1508 

0.0009 

0.1580 

0.0004 

80 

0.1384 

0.0010 

0.1401 

0.0009 

0.1453 

0.0005 

0.1508 

0.0004 

0.1582 

0.0005 

100 

0.1390 

0.0006 

0.1392 

0.0004 

0.1449 

0.0006 

0.1516 

0.0005 

0.1591 

0.0005 
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Table  21  ODMRP,  Received-to-Sent  Ratio,  Satellite  Failures 


Loading 

Non-Satellite 

1-Satellite 

3-Satellite 

5-Satellite 

7-Satellite 

Users 

Levels 

Failure 

Failure 

Failure 

Failure 

Failure 

(%) 

X 

S 

X 

S 

X 

S 

X 

S 

X 

S 

20 

0.9846 

0.0050 

0.9450 

0.0060 

0.8644 

0.0109 

0.8372 

0.0072 

0.7564 

0.0069 

5 

50 

0.9908 

0.0038 

0.9482 

0.0041 

0.8789 

0.0108 

0.8457 

0.0076 

0.7580 

0.0073 

80 

0.9909 

0.0045 

0.9434 

0.0036 

0.8835 

0.0057 

0.8697 

0.0106 

0.7633 

0.0098 

100 

0.9933 

0.0007 

0.9504 

0.0043 

0.8855 

0.0033 

0.8797 

0.0044 

0.7760 

0.0097 

20 

0.9941 

0.0025 

0.9861 

0.0027 

0.9373 

0.0025 

0.9157 

0.0030 

0.9177 

0.0027 

10 

50 

0.9941 

0.0019 

0.9865 

0.0017 

0.9352 

0.0016 

0.9171 

0.0022 

0.9146 

0.0017 

80 

0.9952 

0.0004 

0.9871 

0.0009 

0.9349 

0.0007 

0.9177 

0.0004 

0.9147 

0.0011 

100 

0.9939 

0.0005 

0.9863 

0.0015 

0.9322 

0.0031 

0.9155 

0.0009 

0.9117 

0.0010 

20 

0.9953 

0.0023 

0.9955 

0.0015 

0.9771 

0.0005 

0.9226 

0.0008 

0.9188 

0.0004 

15 

50 

0.9959 

0.0013 

0.9969 

0.0002 

0.9758 

0.0005 

0.9203 

0.0010 

0.9153 

0.0003 

80 

0.9942 

0.0017 

0.9950 

0.0009 

0.9739 

0.0006 

0.9172 

0.0013 

0.9112 

0.0010 

100 

0.9942 

0.0007 

0.9944 

0.0009 

0.9720 

0.0011 

0.9149 

0.0015 

0.9084 

0.0013 
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Table  22  ODMRP,  End-to-End  Delay,  Satellite  Failures 


Loading 

Non-Satellite 

1-Satellite 

3-Satellite 

5-Satellite 

7-Satellite 

Users 

Levels 

Failure 

Failure 

Failure 

Failure 

Failure 

(%) 

X 

S 

X 

S 

X 

S 

X 

S 

X 

S 

20 

0.0673 

0.0005 

0.4372 

0.0910 

0.8331 

0.0407 

0.8448 

0.0205 

1.1014 

0.0279 

5 

50 

0.0690 

0.0001 

0.2236 

0.0388 

0.4077 

0.0192 

0.3736 

0.0126 

0.4997 

0.0165 

80 

0.0709 

0.0002 

0.1758 

0.0271 

0.3053 

0.0107 

0.3028 

0.0118 

0.3661 

0.0205 

100 

0.0723 

0.0003 

0.1737 

0.0180 

0.2753 

0.0109 

0.2795 

0.0102 

0.3380 

0.0127 

20 

0.0608 

0.0002 

0.0668 

0.0016 

0.6211 

0.0174 

0.8203 

0.0099 

0.8194 

0.0096 

10 

50 

0.0622 

0.0001 

0.0655 

0.0004 

0.2988 

0.0051 

0.3811 

0.0033 

0.3859 

0.0023 

80 

0.0638 

0.0001 

0.0669 

0.0004 

0.2199 

0.0047 

0.2758 

0.0031 

0.2796 

0.0029 

100 

0.0653 

0.0002 

0.0682 

0.0004 

0.1965 

0.0037 

0.2488 

0.0037 

0.2508 

0.0028 

20 

0.0628 

0.0000 

0.0644 

0.0000 

0.2759 

0.0088 

0.5604 

0.0099 

0.5566 

0.0097 

15 

50 

0.0645 

0.0021 

0.0644 

0.0000 

0.1505 

0.0035 

0.2617 

0.0039 

0.2636 

0.0041 

80 

0.0656 

0.0005 

0.0664 

0.0001 

0.1233 

0.0024 

0.1928 

0.0022 

0.1959 

0.0023 

100 

0.0676 

0.0001 

0.0678 

0.0001 

0.1161 

0.0017 

0.1741 

0.0017 

0.1771 

0.0018 
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Appendix  B.  ANOVA  Table 


*  Example  ( a  =  significance  level) 


Source  of 

Variation 

Sum  of 

Squares 

Df 

Mean 

Square 

F 

P-value 

F  critical 

value  ( a ) 

Treatments 

SSTr 

/-I 

MSTr 

MSTr 
'  ~  MSE 

Area  under 

F  curve  to 
right  of  / 

F 

1  1) 

Error 

SSE 

i(j-i) 

MSE 

Total 

SST 

U- 1 

Table  23  DVMRP,  5-user,  Data-to-Overhead,  in  No,  3  and  5  satellite  failures 


Foading 

Fevel 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

8.5E-06 

2 

4.3E-06 

50% 

Error 

6.5E-05 

9 

7.2E-06 

0.588 

0.575 

4.256 

Total 

7.4E-05 

11 

Treatments 

4E-05 

2 

2E-05 

80% 

Error 

0.0001 

9 

1.1E-05 

1.783 

0.223 

4.256 

Total 

0.00014 

11 

Treatments 

8.8E-05 

2 

4.4E-05 

100% 

Error 

0.00015 

9 

1.7E-05 

2.569 

0.131 

4.256 

Total 

0.00024 

11 
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Table  24  DVMRP,  5-user,  Data-to-Overhead,  in  3  and  7  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

0.00013 

1 

0.00013 

50% 

Error 

4.3E-05 

6 

7.2E-06 

17.71 

0.006 

5.987 

Total 

0.00017 

7 

Treatments 

7.2E-05 

1 

7.2E-05 

80% 

Error 

6.1E-05 

6 

IE-05 

7.089 

0.0374 

5.987 

Total 

0.00013 

7 

Treatments 

8.6E-05 

1 

8.6E-05 

100% 

Error 

9.1E-05 

6 

1.5E-05 

5.663 

0.055 

5.987 

Total 

0.00018 

7 

Table  25  DVMRP,  5-user,  Data-to-Overhead,  in  1  and  7  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

4E-06 

l 

4E-06 

50% 

Error 

3E-05 

6 

5E-06 

0.811 

0.402 

5.987 

Total 

3.4E-05 

7 

Treatments 

1.9E-05 

1 

1.9E-05 

80% 

Error 

8.6E-05 

6 

1.4E-05 

1.365 

0.287 

5.987 

Total 

0.00011 

7 

Treatments 

8.1E-08 

1 

8.1E-08 

100% 

Error 

0.00012 

6 

1.9E-05 

0.004 

0.951 

5.987 

Total 

0.00012 

7 
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Table  26  DVMRP,  10-user,  Data-to-Overhead,  in  3  and  7  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

4.8E-06 

l 

4.8E-06 

50% 

Error 

IE-05 

6 

1.7E-06 

2.833 

0.143 

5.987 

Total 

1.5E-05 

7 

Treatments 

1.52E-06 

1 

1.5E-06 

80% 

Error 

6.2E-05 

6 

IE-05 

0.147 

0.715 

5.987 

Total 

6.4E-05 

7 

Treatments 

1.21E-08 

1 

1.2E-08 

100% 

Error 

2.4E-05 

6 

3.9E-06 

0.003 

0.958 

5.987 

Total 

2.4E-05 

7 

Table  27  DVMRP,  10-user,  Data-to-Overhead,  in  No  and  1  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

0.0002 

1 

0.0002 

50% 

Error 

3.3E-05 

6 

5.5E-06 

37.054 

9E-04 

5.9874 

Total 

0.00024 

7 

Treatments 

0.00018 

1 

0.00018 

80% 

Error 

5.76E-05 

6 

9.6E-06 

18.739 

0.005 

5.9874 

Total 

0.000237 

7 

Treatments 

0.00024 

1 

0.00024 

100% 

Error 

6.3E-05 

6 

1.1E-05 

22.526 

0.003 

5.9874 

Total 

0.0003 

7 
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Table  28  DVMRP,  15-user,  Data-to-Overhead,  in  No,  3  and  5  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

5E-05 

2 

2E-05 

50% 

Error 

5E-05 

9 

6E-06 

4.124 

0.054 

4.256 

Total 

IE-04 

11 

Treatments 

2E-05 

2 

IE-05 

80% 

Error 

7E-05 

9 

7E-06 

1.524 

0.269 

4.256 

Total 

9E-05 

11 

Treatments 

6E-05 

2 

3E-05 

100% 

Error 

IE-04 

9 

IE-05 

2.655 

0.124 

4.256 

Total 

2E-04 

11 

Table  29  DVMRP,  15-user,  Data-to-Overhead,  in  No  and  7  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

3.8E-05 

l 

3.8E-05 

50% 

Error 

4.9E-05 

6 

8.2E-06 

4.707 

0.073 

5.987 

Total 

8.7E-05 

7 

Treatments 

3.4E-05 

1 

3.4E-05 

80% 

Error 

2.5E-05 

6 

4.2E-06 

8.178 

0.029 

5.987 

Total 

5.9E-05 

7 

Treatments 

0.00014 

1 

0.00014 

100% 

Error 

7.1E-05 

6 

1.2E-05 

11.93 

0.014 

5.987 

Total 

0.00021 

7 
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Table  30  DVMRP,  15-user,  Data-to-Overhead,  in  1  and  7  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

4.6E-06 

l 

4.6E-06 

50% 

Error 

7.5E-05 

6 

1.2E-05 

0.369 

0.566 

5.987 

Total 

7.9E-05 

7 

Treatments 

9.2E-06 

1 

9.2E-06 

80% 

Error 

5.1E-05 

6 

8.5E-06 

1.085 

0.338 

5.987 

Total 

6E-05 

7 

Treatments 

1.3E-06 

1 

1.3E-06 

100% 

Error 

6.2E-05 

6 

IE-05 

0.124 

0.736 

5.987 

Total 

6.3E-05 

7 

Table  31  DVMRP,  15-user,  Received-to-Sent,  in  3,  5  and  7  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

1.3E-05 

2 

6.4E-06 

50% 

Error 

2.5E-05 

9 

2.8E-06 

2.292 

0.157 

4.256 

Total 

3.8E-05 

11 

Treatments 

3.8E-05 

2 

1.9E-05 

80% 

Error 

4.3E-05 

9 

4.7E-06 

3.969 

0.058 

4.256 

Total 

8E-05 

11 

Treatments 

4.9E-05 

2 

2.5E-05 

100% 

Error 

3.8E-05 

9 

4.2E-06 

5.837 

0.024 

4.256 

Total 

8.7E-05 

11 
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Table  32  DVMRP,  5-user,  End-to-End  Delay,  in  No,  1  and  3  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

3.3E-07 

2 

1.6E-07 

50% 

Error 

1.1E-06 

9 

1.2E-07 

1.326 

0.313 

4.256 

Total 

1.4E-06 

11 

Treatments 

6.3E-07 

2 

3.2E-07 

80% 

Error 

IE-06 

9 

1.1E-07 

2.829 

0.1113 

4.256 

Total 

1.6E-06 

11 

Treatments 

3.9E-07 

2 

2E-07 

100% 

Error 

1.9E-06 

9 

2.1E-07 

0.918 

0.434 

4.256 

Total 

2.3E-06 

11 

Table  33  DVMRP,  5-user,  End-to-End  Delay,  in  3  and  5  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

3.9E-06 

l 

3.9E-06 

50% 

Error 

7.2E-07 

6 

1.2E-07 

32.54 

0.001 

5.987 

Total 

4.6E-06 

7 

Treatments 

3.3E-06 

1 

3.3E-06 

80% 

Error 

5E-07 

6 

8.3E-08 

39.81 

0.0007 

5.987 

Total 

3.8E-06 

7 

Treatments 

2.8E-06 

1 

2.8E-06 

100% 

Error 

1.2E-06 

6 

2E-07 

13.91 

0.0097 

5.987 

Total 

4E-06 

7 
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Table  34  DVMRP,  10-user,  End-to-End  Delay,  in  5  and  7satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

1.4E-08 

l 

1.4E-08 

50% 

Error 

5.6E-08 

6 

9.4E-09 

1.520 

0.264 

5.987 

Total 

7.1E-08 

7 

Treatments 

1.5E-08 

1 

1.5E-08 

80% 

Error 

1.3E-07 

6 

2.15E-08 

0.695 

0.436 

5.987 

Total 

1.4E-07 

7 

Treatments 

6.4E-08 

1 

6.4E-08 

100% 

Error 

1.7E-07 

6 

2.8E-08 

2.30 

0.180 

5.987 

Total 

2.3E-07 

7 

Table  35  DVMRP,  10-user,  End-to-End  Delay,  in  No  and  lsatellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

50% 

Treatments 

1.3E-05 

l 

1.3E-05 

1026.8 

6E-08 

5.9874 

Error 

7.8E-08 

6 

1.3E-08 

Total 

1.3E-05 

7 

80% 

Treatments 

1.3E-05 

1 

1.32E-05 

1528.6 

1.9E- 

08 

5.9874 

Error 

5.2E-08 

6 

8.66E-09 

Total 

1.3E-05 

7 

100% 

Treatments 

1.3E-05 

1 

1.3E-05 

375.9 

IE-06 

5.987 

Error 

2.1E-07 

6 

3.4E-08 

Total 

1.3E-05 

7 
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Table  36  DVMRP,  15-user,  End-to-End  Delay,  in  1  and  3  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

4E-08 

l 

4E-08 

50% 

Error 

9.2E-08 

6 

1.5E-08 

2.608 

0.157 

5.987 

Total 

1.3E-07 

7 

Treatments 

1.1E-07 

1 

1.1E-07 

80% 

Error 

2.2E-08 

6 

3.7E-09 

30.92 

0.001 

5.987 

Total 

1.4E-07 

7 

Treatments 

1.2E-07 

1 

1.2E-07 

100% 

Error 

1.4E-07 

6 

2.4E-08 

5.102 

0.065 

5.987 

Total 

2.7E-07 

7 

Table  37  DVMRP,  15-user,  End-to-End  Delay,  in  1  and  7  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

7.6E-08 

l 

7.6E-08 

50% 

Error 

4.2E-08 

6 

6.9E-09 

10.94 

0.016 

5.987 

Total 

1.2E-07 

7 

Treatments 

9.3E-08 

1 

9.3E-08 

80% 

Error 

2.4E-08 

6 

4E-09 

23.2 

0.003 

5.987 

Total 

1.2E-07 

7 

Treatments 

3.4E-08 

1 

3.4E-08 

100% 

Error 

1.6E-07 

6 

2.7E-08 

1.262 

0.304 

5.987 

Total 

2.7E-07 

7 
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Table  38  ODMRP,  15-user,  Received-to-Sent,  in  No  and  1  satellite  failure 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

9E-08 

l 

9E-08 

20% 

Error 

2.2E-05 

6 

3.7E-06 

0.024 

0.882 

5.987 

Total 

2.3E-05 

7 

Treatments 

2.1E-06 

1 

2.1E-06 

50% 

Error 

5.6E-06 

6 

9.3E-07 

2.217 

0.187 

5.987 

Total 

7.7E-06 

7 

Treatments 

1.2E-06 

1 

1.2E-06 

80% 

Error 

1.1E-05 

6 

1.9E-06 

0.636 

0.455 

5.987 

Total 

1.3E-05 

7 

Treatments 

6.6E-08 

1 

6.6E-08 

100% 

Error 

3.9E-06 

6 

6.5E-07 

0.103 

0.7595 

5.987 

Total 

3.9E-06 

7 

Table  39  ODMRP,  10-user,  End-to-End  Delay,  in  5  and  7  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

0.001 

l 

0.0011 

20% 

Error 

0.008 

6 

0.0013 

0.825 

0.399 

5.987 

Total 

0.009 

7 

Treatments 

4.6E-05 

1 

4.6E-05 

50% 

Error 

4.9E-05 

6 

8.1E-06 

5.645 

0.055 

5.987 

Total 

9.5E-05 

7 

Treatments 

2.8E-05 

1 

2.8E-05 

80% 

Error 

5.3E-05 

6 

8.9E-06 

3.148 

0.126 

5.987 

Total 

8.1E-05 

7 

Treatments 

8E-06 

1 

8E-06 

100% 

Error 

6.6E-05 

6 

1.1E-05 

0.733 

0.425 

5.987 

Total 

7.4E-05 

7 
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Table  40  ODMRP,  10-user,  End-to-End  Delay,  in  3  and  5  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

0.07937 

1 

0.079 

1.05E- 

06 

20% 

Error 

0.0012 

6 

0.0002 

395.691 

5.987 

Total 

0.08058 

7 

Treatments 

0.0136 

1 

0.014 

50% 

Error 

0.0001 

6 

2E-05 

728 

2E-07 

5.987 

Total 

0.0137 

7 

Treatments 

0.0063 

1 

0.006 

80% 

Error 

9E-05 

6 

2E-05 

397.36 

IE-06 

5.987 

Total 

0.0063 

7 

Treatments 

0.00548 

1 

0.005 

9.98E- 

07 

100% 

Error 

8.2E-05 

6 

1.36E-05 

402.185 

5.987 

Total 

0.00556 

7 

Table  41  ODMRP,  15-user,  End-to-End  Delay,  in  5  and  7  satellite  failures 


Loading 

Level 

Source  of 

Variation 

Sum  of 

Squares 

df 

Mean 

Square 

F 

P- 

value 

F  critical 

value  (0.05) 

Treatments 

3E-05 

l 

2.9E-05 

20% 

Error 

0.0006 

6 

9.6E-05 

0.298 

0.605 

5.987 

Total 

0.0006 

7 

Treatments 

6.7E-06 

1 

6.7E-06 

50% 

Error 

9.7E-05 

6 

1.6E-05 

0.417 

0.542 

5.987 

Total 

0.0001 

7 

Treatments 

1.9E-05 

1 

1.9E-05 

80% 

Error 

3E-05 

6 

4.9E-06 

3.946 

0.094 

5.987 

Total 

4.9E-05 

7 

Treatments 

1.8E-05 

1 

1.8E-05 

100% 

Error 

1.8E-05 

6 

3.1E-06 

5.881 

0.052 

5.987 

Total 

3.6E-05 

7 
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ODMRP  has  an  enormous  end-to-end  delay  in  severe  failure  conditions.  In  contrast,  DVMRP  suffered  broken  routes  and  complexity  in  large  group 
membership  densities  and  satellite  failure  conditions.  It  demonstrated  a  less  reliable  packet  delivery  than  ODMRP.  DVMRP  has  the  advantage  of 
scalable  and  stable  end-to-end  delay  under  multiple  failed  satellite  conditions. 
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